Gateway Architectures

Gateway Architectures

Before digging into the nuts and bolts of organizing OTAU deployments and managing a fleet of IoT gateways, this section defines some topographies and separates them into Classes. It is important to understand how your IoT gateway fleet is organized because it can affect how OTAU deployments are executed and monitored/verified.

@startuml
!include gwe-style.iuml

title Architecture Diagram Legend
legend left
<i><b>Glossary</b></i>

CGA - The Custom Gateway Application managed by <i><b>gwe</b></i>.
gwe - The Gateway Engine process (<i><b>gwe</b></i>).
gmq - The Gateway Message Queue process (<i><b>gmq</b></i>).
supervisord - The <i><b>supervisord</b></i> process maintaining process states and other functions like log rotation.
Product - A Murano Product in a Murano Business you either own or have been invited to.

<i><b>Lines and Colors</b></i>

|= |= Type |
| - | Solid lines are mandatory. |
|- -| Dashed lines are optional. |
|<back:SUPERVSR>   </back>| Supervisor Monitoring and Control |
|<back:MURANOCOM>   </back>| HTTPS/MQTT Connection |

endlegend
@enduml

Class A

A typical IoT environment where gateways are a part of the overall ecosystem generally look something like the representation below.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class A - Typical Gateway Architecture</b>
    CGA connects with its own HTTPS/MQTT library.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder Product ONEP {
            folder Device PYTHON [
                <i>resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

Device <-[MURANOCOM]do- gwe
Device <-[MURANOCOM]do- CGA

@enduml

Important

Device Identity

In a Class A-D architectures, the CGA uses the connection identity and credentials of gwe. This is often done as a matter of convenience since using GWE can simplify identity and provisioning considerations.

Class B

Another typical way IoT gateways are architected is when the CGA uses either the device-client python library or the gdc command-line interface to read/write/connect to Exosite.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class B Architecture</b>
    CGA is a Python or Shell app that uses <i><b>gdc</b></i> to connect.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
                rectangle "CGA" as CGA CUSTOMAPP {
                }
            }
        }
    rectangle supervisord SUPERVSR
    }

}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder Product ONEP {
            folder Device PYTHON [
                <i>resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

Device <-[MURANOCOM]do- gwe
Device <-[MURANOCOM]do- CGA

@enduml

Class C

This IoT gateway architecture is when the CGA uses gmq to read/write/connect to Exosite.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class C Architecture
    CGA is a linux process that uses the <i><b>gmq</b></i>
    API to communicate with Exosite.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder Product ONEP {
            folder Device PYTHON [
                <i>resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

Device <-[MURANOCOM]do- gwe
Device <-[MURANOCOM]do- gmq
gmq <-[MURANOCOM]do- CGA

@enduml

Class D

This IoT gateway architecture is when the CGA uses a mixed communication scenario. For instance, the CGA will use gmq to read/write/connect to Exosite as well as its own HTTPS/MQTT connection methods to communicate on the internet or to read configuration data from Exosite.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class D Architecture
    CGA is a linux process that uses <i><b>gmq</b></i> as
    well as its own HTTPS/MQTT connection methods.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder Product ONEP {
            folder Device PYTHON [
                <i>resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

Device <-[MURANOCOM]do- gwe
Device <-[MURANOCOM]do- gmq
gmq <-[MURANOCOM]do- CGA
Device <-[MURANOCOM]do- CGA

@enduml

Class AA

A Class AA architecture is similar to a Class A except that it breaks up the identity of the CGA from gwe. In this case, there will be two Products in a given Murano Business with different resources.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class AA Architecture</b>
    CGA connects with its own HTTPS/MQTT library using
    different identity and credentials than <b>gwe</b>.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder GWE_Product ONEP {
            folder GWE_Device PYTHON [
                <i>gwe resources</i>
            ]
        }
        folder CGA_Product ONEP {
            folder CGA_Device PYTHON [
                <i>cga resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

GWE_Device <-[MURANOCOM]do- gwe
CGA_Device <-[MURANOCOM]do- CGA

@enduml

Class BB

A Class BB architecture is similar to a Class B except that it breaks up the identity of the CGA from gwe. In this case, there will be two Products in a given Murano Business with different resources.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class BB Architecture</b>
    CGA is a Python or Shell app that uses <i><b>gdc</b></i> to
    connect using different identity and credentials than <b>gwe</b>.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
                rectangle "CGA" as CGA CUSTOMAPP {
                }
            }
        }
    rectangle supervisord SUPERVSR
    }

}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder GWE_Product ONEP {
            folder GWE_Device PYTHON [
                <i>gwe resources</i>
            ]
        }
        folder CGA_Product ONEP {
            folder CGA_Device PYTHON [
                <i>cga resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

GWE_Device <-[MURANOCOM]do- gwe
CGA_Device <-[MURANOCOM]do- CGA

@enduml

Class CC

Similar to a Class C architecture, configuration is when the CGA uses gmq to read/write/connect to Exosite but does so with different a different identity and credentials than gwe.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class CC Architecture
    CGA is a linux process that uses the <i><b>gmq</b></i> API to communicate
    with Exosite using different identity and credentials than <b>gwe</b>.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder GWE_Product ONEP {
            folder GWE_Device PYTHON [
                <i>gwe resources</i>
            ]
        }
        folder CGA_Product ONEP {
            folder CGA_Device PYTHON [
                <i>cga resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

GWE_Device <-[MURANOCOM]do- gwe
CGA_Device <-[MURANOCOM]do- gmq
gmq <-[MURANOCOM]do- CGA

@enduml

Class DD

Similar to a Class D architecture, the CGA uses a mixed communication scenario, but does so with different a different identity and credentials than gwe.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

title
    <b>Class DD Architecture
    CGA is a linux process that uses <i><b>gmq</b></i> as well
    as its own HTTPS/MQTT connection methods using
    different identity and credentials than <b>gwe</b>.
end title

' network building blocks
rectangle "Linux" #EFEFEF {
    rectangle "Python" PYTHON {
        rectangle "Gateway Engine" as GWE GATEWAYENGINE {
            rectangle "device-client" as GDC DEVICECLIENT {
                rectangle gwe
                rectangle gmq
            }
        }
    rectangle supervisord SUPERVSR
    }
    rectangle "CGA" as CGA CUSTOMAPP {
    }
}

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        folder GWE_Product ONEP {
            folder GWE_Device PYTHON [
                <i>gwe resources</i>
            ]
        }
        folder CGA_Product ONEP {
            folder CGA_Device PYTHON [
                <i>cga resources</i>
            ]
        }
    }
}

' stitch the network together
gmq o-[SUPERVSR]- supervisord
gwe o-[SUPERVSR]- supervisord
CGA o-[SUPERVSR]- supervisord

GWE_Device <-[MURANOCOM]do- gwe
CGA_Device <-[MURANOCOM]do- gmq
gmq <-[MURANOCOM]do- CGA
CGA_Device <-[MURANOCOM]do- CGA

@enduml

IoT Fleet Management

Inevitably, an update to some software on atleast one gateway will need to be made. This section is not meant to be an exhaustive guide on Continuous Integration or Fleet Management, rather an overview on how IoT gateway fleet maintainers can do a minimum to create an environment to create a development/staging environment for vetting over the air updates with non-production assets.

The Minimal Case

A minimal IoT gateway environment.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

cloud Exosite ONEP

rectangle "02:42:AC:11:00:01" as 1 GATEWAYENGINE
rectangle "02:42:AC:11:00:02" as 2 GATEWAYENGINE
rectangle "02:42:AC:11:00:03" as 3 GATEWAYENGINE

Exosite -[MURANOCOM]0- 1
Exosite -[MURANOCOM]0- 2
Exosite -[MURANOCOM]0- 3

@enduml

Though the environment described by the diagram is typical to most environments, it fails to address the problem of OTAU rollouts and fleet maintenance.

A More Robust Case

Before deploying any over the air update, it should be tested in a test environment. To create a test environemt, make a copy of the production Murano Product and connect to test gateways to it and test the OTAU.

@startuml
!include gwe-style.iuml
skinparam arrowThickness 4

cloud Exosite {
    rectangle "Murano Business" ExoLightGray {
        rectangle Product_Prod ONEP
        rectangle Product_Dev ONEP
    }
}

rectangle "02:42:AC:11:00:01" as 1 GATEWAYENGINE
rectangle "02:42:AC:11:00:02" as 2 GATEWAYENGINE
rectangle "02:42:AC:11:00:03" as 3 GATEWAYENGINE

rectangle "02:42:AC:11:00:04" as 4 GATEWAYENGINE
rectangle "02:42:AC:11:00:05" as 5 GATEWAYENGINE
rectangle "02:42:AC:11:00:06" as 6 GATEWAYENGINE

Product_Prod -[MURANOCOM]0- 1
Product_Prod -[MURANOCOM]0- 2
Product_Prod -[MURANOCOM]0- 3

Product_Dev -[MURANOCOM]0- 4
Product_Dev -[MURANOCOM]0- 5
Product_Dev -[MURANOCOM]0- 6

@enduml