- [Neel] Hello builders, what's up? I am Neel Mitra, Principal Product Solutions Architect, working with AWS Industry Products team. Raf and Alana have already introduced you to the what and why of Industrial IoT, an edge-to-cloud continuum. I'm here to take your journey forward with the how. So, think of the scenario, one of your factories is producing a lot of defective cupcakes, (sad trumpet plays) that's impacting the supply chain for that locality and customer experience. Think of those unhappy, sad little kids. The traditional solution that exists today is not optimal as it needs data from multiple cycles, across factories, spending days or weeks. Your mission, (excited music) as an industrial IT engineer, if you choose to accept, you have 5 seconds. Tick, tick. I'm just kidding. Your mission is to develop an edge solution that can help process the data in near real time, to monitor the current quality, and even predict the upcoming ones based on data, or OPC-UA tags, collected from different sensors, actuators, associated with the production lines. In summary, you want way fewer defective cupcakes. So, the next obvious question is, hey Neel, do you have an idea, which AWS edge service can help? Sure. Drum rolls, please. (drum rolls) Here comes AWS IoT Greengrass 2.0. Just a quick disclaimer from here onwards. Whenever I talk about this service, please note I'm referring to its latest version, AWS IoT Greengrass 2.0. Sound delicious? Let's dive deep. AWS IoT Greengrass 2.0 is an open-source software. This service is built for operating across different platforms, such as X86 and ARM architectures, on different Linux platforms, or as Docker containers. How awesome is that? It requires at least 1 gigahertz of compute and 96 MB of RAM. This service is also qualified on hardwares from different silicon partners. In terms of feature set, AWS IoT Greengrass 2.0 supports local data processing, orchestrations, stream analytics, and machine learning on the edge. Thus, even if there is no cloud connectivity, the intelligent operations on the factory plant can continue. Greengrass is designed to offer at least 99.9 percent SLA, that is critical for connected factories. Greengrass has two parts. First, an edge runtime, that is an open-source software under Apache 2.0 license. This can be installed on the industrial gateways on the factory plant. Second, a cloud counterpart that helps you manage the edge runtime, along with developing and deploying custom applications from your organization. Greengrass brings some great features out of the box. Those include a rich set of prebuilt software components developed by AWS. Access to local resources, such as serial interfaces or GPIO, tools for local software development on your local machine or cloud environment, and advanced features to maintain a large fleet of devices. On top of that, it's modular. Are you thinking: What is a component, though? Great minds think alike. This is the most important concept of Greengrass. Components are software modules that you deploy and run on the edge runtime. This enables easy creation of complex workflows. Being modular, the only component that you really need for Greengrass to be up and running is called Nucleus. Think of Nucleus as the heart of Greengrass. And after that, you can add prebuilt software components, such as Stream Manager, MQTT Broker, OPC-UA Collector, Log Manager, et cetera, et cetera, et cetera. These components can help accelerate your application development. So, you don't have to worry about understanding device protocols, managing credentials, or interact with external APIs. And you can interact with AWS services and third-party applications without writing code. How amazing is that? Components also enables you to reuse common business logic from one AWS IoT Greengrass device to another, as you can easily discover, import, configure, and deploy components at the edge. Or, you can develop and bring your own components based on the use case and the device horsepower. So, we'll assume that your industrial gateway follows a standard manufacturing process, comes embedded with the Greengrass software and cryptographic credentials, such as X509 certificates. Now, when the device wakes up for the first time, it will go through a bootstrapping process, which is very common with IoT, and the files will be registered with cloud using specified privileges. Now, Greengrass can wear multiple hats. It can act as an individual, powerful device or a gateway, which is the case here, to multiple sensors, peripherals, or embedded devices. Awesome. So now, your fictitious Greengrass device is up and running. What's next? Let's start collecting some data, yeah. Greengrass offers different ways to interface with edge devices or peripherals. For example, it supports protocols-- such as Modbus, TCU- and RTP-based; MQTT; Ethernet; IP; OPC-UA-- out of the box. How cool is that? If your use case requires a custom protocol, you can deploy your own custom component as a native process; as serverless functions, such as Lambda; or a container image, to do the decentralization on the edge, as well. So now, let's recall our scenario and figure out if the cupcakes are crumbling in the production line. Thus, we need to process the tags generated from the sensors and actuators on the production line, by retrieving it through an OPC-UA server. Greengrass offers a prebuilt component called IoT SiteWise OPC-UA Collector that helps collect all these tags from the most common OPC-UA servers. Once the tags are collected, it can be processed by other Greengrass components as local events. For example, these tags can be persisted within Greengrass in a local stream analyzed by local processes, or machine learning models. And the OEE results can be displayed on a local dashboard on the plant floor. And all these operations can continue, even if there is no cloud connectivity. I repeat: even if there is no cloud connectivity. That's the beauty of Greengrass, offline processing, and online connectivity, when available. So when connectivity is available, these tags can also be published directly to cloud through another component or MQTT broker. The connectivity also helps with over-the-air updates. Let's say you need to push the latest version of your code or machine learning models onto the edge, but also remember, the data has more value when it's adjacent to more data. Thus, you can filter out noisy data, and publish tags that adds value to the data lake on cloud. That helps to store historical data, perform advanced analytics, publishing data to other data streams, performing machine learning trainings, or integrate with your existing IT systems, such as ERP or CRM. That's magical, right? Who knew you can identify defective cupcakes in near real time? Hope by now you understand the value of Greengrass 2.0, in theory, and you will learn a lot more as you get your hands on in the upcoming exercises, using local toolsets that Greengrass offers.
