Skip to content
This repository has been archived by the owner on Feb 5, 2024. It is now read-only.

Commit

Permalink
Uploaded the design decisions (#85)
Browse files Browse the repository at this point in the history 
* Uploaded the design decisions

I forgot to upload the design decisions - sorry!

* Update design_decisions_server.md

little changes

* Update design_decisions_paho.md

* Update design_decisions_paho.md
  • Loading branch information
@Emirhan-Atabay
Emirhan-Atabay authored Aug 22, 2022
1 parent c24929c commit 6406726
Show file tree
Hide file tree
Showing 6 changed files with 141 additions and 0 deletions.
23 changes: 23 additions & 0 deletions docs/design_decision_mqtt.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Design decision

| Status | <span style="color:green">Accepted</span> |
|--------------|:---------:|
| <b>Contributors</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Approved</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Due date</b> | 15.06.2022 |
| <b>Decision on</b> | MQTT vs self contributing |

|Problem statement|
|--------------|
|We could use MQTT or contribute our own protocol to exchange data from the ESP32 and the server.|

|Solution hypothesis|
|--------------|
|The Server structure depends on the choice we take on the protocol.|

| | Option 1 | Option 2 |
|--|--|--|
|<b>Overview</b>|MQTT|self contributing|
|<b>Link</b>|[MQTT](https://mqtt.org)|-|
|<b>Benefits and risks</b>|+ MQTT is the standard for IoT Messaging<br>+ is lightweigt and efficient<br>+ supports Bi-directional communication<br>+ can scale up to Millions of Things<br>+ easy to encrypt messages using TLS<br>+ Support for unreliable Networks<br>+ Reliable Message Delivery|+ customizable<br>– takes time to implement<br>– Why reinvent the wheel when there is already a standard messaging protocol for IoT?|
|<b>Criteria</b>|+ is lightweight<br>+ secure<br>+ highly scaleble<br>+ reliable|– Why reinvent the wheel?|
23 changes: 23 additions & 0 deletions docs/design_decisions_chip.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Design decision

| Status | <span style="color:green">Accepted</span> |
|--------------|:---------:|
| <b>Contributors</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Approved</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Due date</b> | 05.05.2022 |
| <b>Decision on</b> | Customize an existing example program from connectedhomeip to our needs or develop a completely new program |

|Problem statement|
|--------------|
|We have the choice between developing a completely new program that fits the matter specification or we could use the things which are already implemented by the Connectivity Standard Alliance. We could change the example programs in a way, that fits our needs.|

|Solution hypothesis|
|--------------|
|The MatterHub can interact with the end device once the program is implemented.|

| | Option 1 | Option 2 |
|--|--|--|
|<b>Overview</b>|using an Example File from connectedhomeip and customizing it|self contributing|
|<b>Link</b>|[connectedhomeip on GitHub](https://github.com/project-chip/connectedhomeip)|-|
|<b>Benefits and risks</b>|+ We can use the existing code and only need to change it a bit<br>– too complicated<br>– too many files to look for<br>– no Documentation so we need to try to find out|– too many dependencies to consider<br>– no API or Documentation<br>– Why reinventing the wheel when connectedhomeip gives us the basic functionality|
|<b>Criteria</b>|+ we can use the existing code <br>– no Documentation|– Why reinvent the wheel? |
23 changes: 23 additions & 0 deletions docs/design_decisions_paho.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Design decision

| Status | <span style="color:green">Accepted</span> |
|--------------|:---------:|
| <b>Contributors</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Approved</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Due date</b> | 23.06.2022 |
| <b>Decision on</b> | Server library |

|Problem statement|
|--------------|
|Eclipse Tahu provides a Sparkplug specific library while Eclipse Paho provides generic MQTT support.|

|Solution hypothesis|
|--------------|
|Our choice decides on using a Sparkplug specific library or generic MQTT support with Paho.|

| | Option 1 | Option 2 |
|--|--|--|
|<b>Overview</b>|Tahu with Sparkplug support|Paho with generic MQTT support|
|<b>Link</b>|[Tahu](https://github.com/eclipse/tahu)|[Paho](https://www.eclipse.org/paho)|
|<b>Benefits and risks</b>|+ supports HiveMQ<br>+ Metrics and message format brings convention and consistency|+ supports HiveMQ<br>+ generic MQTT support|
|<b>Criteria</b>|– is not generic<br>– too complicated and not flexible enough for our use case<br>– We have no advantage from the Standard Compliance<br>– We only use 4 of 9 message types<br>– We don't use Protobuf<br>– Message format is too advanced|+ generic MQTT support<br>+ more flexible<br>– missing metrics —> we could use our own message format instead|
24 changes: 24 additions & 0 deletions docs/design_decisions_server.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# Design decision

| Status | <span style="color:green">Accepted</span> |
|--------------|:---------:|
| <b>Contributors</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Approved</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Due date</b> | 17.06.2022 |
| <b>Decision on</b> | Server structure |

|Problem statement|
|--------------|
|We need a structure for our server, so the ESP32 (our Hub) and M5stack (our end device) can interact with the Bosch IOT Things Cloud. We could directly send it to IOTT from the end device. We could implement an MQTT Broker as an intermediate as well which gets the topics by publishing and subscribing, transform them into commands and then send it to IOTT. Transforming in HiveMQ is difficult to implement so we could use a JAVA Rest Client as an intermediate as well.|

|Solution hypothesis|
|--------------|
|The Bosch IOT Things Cloud can interact with the end device and our MatterHub once the program is implemented.|


| | Option 1 | Option 2 | Option 3 |
|--|--|--|--|
|<b>Overview</b>|<b>HiveMQ</b> + IOTT|HiveMQ + <b>Rest Client</b> + IOTT|sending <b>directly to IOTT</b>|
|<b>Link</b>|[HiveMQ](https://www.hivemq.com)|-|[Bosch IoT Things](https://docs.bosch-iot-suite.com/things/)|
|<b>Benefits and risks</b>|+ HiveMQ is a good MQTT Broker that the industry is using<br>– transforming received messages into commands is not efficient with HiveMQ|+ HiveMQ is a good MQTT Broker that the industry is using<br>– The Server must be set up too —> takes much time|+ We don't have an intermediate server —> The more Server we need, the more it would cost<br>– The Clients (ESP32) must have good CPU and RAM|
|<b>Criteria</b>|+ works fine with Sparkplug<br>– transforming commands not efficient with MQTT|+ transforming MQTT messages into commands is more efficient than using HiveMQ for the transformation<br>+ works fine with Sparkplug<br>– takes much time to set up the server|– The ESP32 is not strong enough|
23 changes: 23 additions & 0 deletions docs/design_decisions_sparkplug.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# Design decision

| Status | <span style="color:green">Accepted</span> |
|--------------|:---------:|
| <b>Contributors</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Approved</b> | @Emirhan-Atabay @bowski23 @Ti-ger @vringar @TuCl |
| <b>Due date</b> | 20.06.2022 |
| <b>Decision on</b> | Which server specification is working better with MQTT? |

|Problem statement|
|--------------|
|We need a mechanism to send and receive messages from the MQTT Server. Should we take an existing specification like Tahu or Sparkplug or should we implement it by ourselves.|

|Solution hypothesis|
|--------------|
|We can send and receive messages through the end device (ESP32) and we can provide the communication to the server.|

| | Option 1 | Option 2 | Option 3 |
|--|--|--|--|
|<b>Overview</b>|Tahu (raw MQTT Client)|Sparkplug|self contributing|
|<b>Link</b>|[Tahu Documentation](https://projects.eclipse.org/projects/iot.tahu)|[Sparkplug Documentation](https://www.eclipse.org/tahu/spec/Sparkplug%20Topic%20Namespace%20and%20State%20ManagementV2.2-with%20appendix%20B%20format%20-%20Eclipse.pdf)|-|
|<b>Benefits and risks</b>|+ can be customized<br>– there are already good existing solutions like Sparkplug<br>– no Topic Namespace Elements —> We need to implement it by ourself or map the topics to the commands|+ fully auto discover tags [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ state aware [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ open standard [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ provides industry interoperability with open standard [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ has Topic Namespace Elements (—> no need for mapping => lower latency and costs)|+ independent from other programs<br>– takes too long to develop<br>– there are already existing solutions that work better with MQTT|
|<b>Criteria</b>|+ MQTT spec is only 80 pages<br>– not much time left to implement it by ourself<br>– Sparkplug is better and easier|+ simple (=> MQTT spec is 80 pages and Sparkplug adds another 60 pages) [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ Open Source (=> license-free to use —> better for Bosch) [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ Lightweight (=> minimizing the data footprint and leading to more efficient communication) [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ Flexible (=> subscribers don't need to know who provides the information they subscribed) [(source)](https://cirrus-link.com/mqtt-sparkplug-tahu/)<br>+ powerful tool which is easy to implement and doesn't takes much time to develop new features<br>+ works fine with HiveMQ|+ we can customize it more<br>– takes too long to develop|
25 changes: 25 additions & 0 deletions docs/design_decisions_temp.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Design decision

| Status | <span style="color:green">started</span> |
|--------------|---------|
| <b>Contributors</b> | Contributed by |
| <b>Approved</b> | Approved by |
| <b>Due date</b> | Due date |
| <b>Decision on</b> | Topic |

|Problem statement|
|--------------|
|Describe the problem you're trying to solve
and explain why it's important to your customers|

|Solution hypothesis|
|--------------|
|Describe the results and user experience you expect
once you implement your solution|

| | Option 1 | Option 2 | Option 3 |
|--|--|--|--|
|<b>Overview</b>|-|-|-|
|<b>Link</b>|-|-|-|
|<b>Benefits and risks</b>|+ <br>– |+ <br>– |+ <br>– |
|<b>Criteria</b>|+ <br>– |+ <br>– |+ <br>– |

0 comments on commit 6406726

Please sign in to comment.