...

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 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.

Platform Architecture

<Hardware components should be specified with model numbers, part numbers etc>This blueprint describes a self-contained system with the master, deploy and CI/CD nodes running on dedicated on-premises hardware and edge and sensor nodes running on a private network under the customer/user's control. The details of the hardware and network setup can be customized by the user as they see fit. 

The table below summarizes the platform for each node in the blueprint.

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.

Software Platform Architecture

<Software components with version/release numbers >

<EDGE Interface>

<ETSI MEC Interaction>

APIs

APIs with reference to Architecture and Modules

High Level definition of APIs are stated here, assuming Full definition APIs are in the API documentation

Hardware and Software Management

Licensing

...

The software components used by the blueprint are listed below.

• Master node:
  • OS: Ubuntu 20.04
  • Cluster management: Kubernetes 1.22.6
  • Cluster networking: Flannel 0.16.3 (CNI plugin 1.0.1)
  • Container repository: Docker Registry 2.7.1
  • Container runtime: Docker 20.10.7
  • MQTT broker: Mosquitto 2.0.14
• Deploy node:
  • OS: Ubuntu 20.04
  • Deploy scripting: Ansible 4.9.0
• Edge node:
  • OS: Ubuntu 20.04
  • Cluster service: kubelet 1.22.6
  • Container runtime: Docker 20.10.7
  • Edge services: EdgeX Foundry 2.1.0
• Sensor node:
  • OS: Rasbian 11.1
  • Scripting: Python 3.9.2
•  CI/CD:
  • Build automation: Jenkins 2.319.2
  • Test scripting: Robot Framework 4.1.2

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.

APIs

No additional APIs are defined by this blueprint.

The LoRa device service adds a new device profile to the EdgeX Foundry metadata supporting temperature and humidity readings from the DHT-11 sensor over the LoRa connection, and control of the sensor sampling interval. The LoRa connection parameters (channel, group and station IDs) are controlled via configuration values for the LoRa service.

Hardware and Software Management

Hardware provisioning and software management is described in the installation guide. Software is managed using Ansible playbooks and Kubernetes tools such as kubectl via the command line.

Licensing

• Scripts and additional source for the LoRa device service and synchronization application are licensed under the Apache 2.0 license. TBD