...

The diagram below shows the overall architecture of this Release7 blueprint. The colored components represent customizations updated or new implementations added for this Release7 blueprint. The details of the edge node and inter-edge data sharing are further illustrated below.

Image RemovedImage Added

The Smart Data Transaction for CPS blueprint consists of the following types of node roles.

• CI/CD: Runs Jenkins to log into build node, then pull source and scripts, build components and run tests.
• Build: Pull source and scripts, build components and run tests.
• Deploy: Runs scripts (mainly Ansible playbooks) to install components on master and edge nodes.
• Master: Runs the Kubernetes controller for orchestrating the edge nodes, a local docker registry providing container images for the edge nodes, and mosquitto (MQTT broker) for collecting data from edge nodes and sending commands to them.
• Edge: Collects sensor  Collects image data from camera, performs edge processing, and forwards data to the MQTT broker on the master node.
• Sensor: May be a smart sensor or a device containing sensor hardware and a communications Camera: IP camera device (e.g. LoRaHW-500E6A) so that sensing image data can be collected remotely by the edge nodes.

...

The diagram below shows the details of the edge node. The edge node runs an instance of the EdgeX Foundry microservices stack. The EdgeX Foundry stack is instantiated on multiple edge nodes using Kubernetes from the master node.

Image RemovedImage Added

The new LoRa camera device service can provide low-power radio connectivity to remote sensor camera nodes from the edge nodes. The device proxy rest service and synchronization application service allow edge nodes to share data. 

The new image application service can provide image analysis or image comparison of different edge nodes.

The diagram below illustrates the architecture for data sharing between two edge nodes. (The green and red lines show flows of data originating on the left and right nodes respectively.) The decision whether to share a piece of data and with which nodes is under the control of custom rules configured in the EdgeX Foundry rules engine service. The synchronization application picks up the data marked by the rules engine and forwards it to the appropriate edge node through the cluster network. The shared data is received by the device proxy servicerest service, which forwards it to the core data service where it can be processed as a regular event, including such processing as sending commands to local sensors based on the content of that event and configured rules.Image Removed

Image Added

The diagram below shows the details of the image application service.

Image Added

Platform Architecture

...

The specifications above are those used for the blueprint implementation for testing, but other base hardware or OS choices could easily be supported in many cases.

...

• Master node:
  • OS: Ubuntu 20.04
  • Cluster management: Kubernetes 1.22.69
  • Cluster networking: Flannel 0.1617.3 0 (CNI plugin 1.0.1)
  • Container repository: Docker Registry 2.78.1
  • Container runtime: Docker 20.10.712
  • MQTT broker: Mosquitto 2.0.14
• Deploy node:
  • OS: Ubuntu 20.04
  • Deploy scripting: Ansible 45.96.0
• Edge node:
  • OS: Ubuntu 20.04
  • Cluster service: kubelet 1.22.69
  • Container runtime: Docker 20.10.712
  • Edge services: EdgeX Foundry 2.1.0
• Sensor node (R6 configuration):
  • OS: Rasbian 11.1
  • Scripting: Python 3.9.2
• Camera (R7 configuration):
  • Built-in embedded software
•  CI/CD:
  • Build automation: Jenkins 2.319332.23
  • Test scripting: Robot Framework 45.1.20

The current blueprint does not describe external interfaces e.g. to cloud services. The MQTT broker could be configured to supply data and control interfaces to an external service, but the blueprint does not define that functionality.

...