Normally it is the subject of a separate document, but in this case, due to the illustrative character of the task, only the following two fragments are provided:
-
Build an entire architecture for an electric meter using protocol buffers, GRPC and the oneM2M standard.
-
Apply a time series driven approach for energy consumption by using proper TS database(s) and/or streaming and logging systems
-
Explain how to apply Apache Beam in Google Cloud Dataflow for the approach above. Describe how it works and where it fits in the applied architecture
-
Business scenario encompasses the architecture you can pick up a use case (any use case should serve the purpose) and as we told you, we plan on using the data for monitoring, analytics, distributions etc… → scalability is on all levels from sending and receiving to saving.
-
you can choose a random electric meter (which influences the M2M gateway and all sort of stuff) and study its data sheet to find answers
According to the task definitions and received explanations, the next boundary additional conditions have been set:
The purpose of the system (electric meter collector application, EMCA) is limited to electricity billing use cases, which involve the use of data with hourly granulation
-
reliable collection, transmission and storage of electricity consumption data
-
query API for client companies, which
-
perform periodic billing with usage of customer’s tariff plans
-
monitor runtime electricity consumption with a multi-level aggregation (group of meters, house, district, town, region)
-
analyze long-term trends in electricity consumption
-
Since oneM2M technology is not an obvious mainstream, I suspect that real features and performance of compatible devices and gateways can vary widely. In this sense, the proposed system architecture in regards to interaction with the oneM2M infrastructure is based on the following assumptions and limitations
-
Receiving data from a physical device is a responsibility of ADN-AE application, provided by device’s vendor, and it is completely outside the scope of the system
-
Up to some hierarchical level of infrastructure (group of meters, floor, house and so on), reliable data transmission is responsibility of MD-CSE applications and is outside the scope of the system too
-
interaction between system and oneM2M infrastructure is performed by the MC-AE application installed in the gateway on a certain hierarchical level of infrastructure
-
this MC-AE application is in the scope of the system. Interaction between it and other system services is performed without oneM2M infrastructure
-
the MC-AE has to be able to interact with different forms of resources, published by ADN-AE application, provided by different vendor.
-
Since this document is not a System Design Specification (and due to a lack of time), a lot of aspects (for example, the message structure) is presented with a minimum of technical detail required to illustrate the proposed architectural principles. For the same reason, the details of the orchestration of individual services were not deeply discussed.
Also, due to the illustrative character of the task, a lot of structurally required chapters (for example, "Reference documents", "Definitions" or "Abbreviations and Acronyms) was omitted.
-
As this document is short-lived and not designed to edit collaboratively, the adoc ⇒ pdf technology was optimal. Otherwise I’d be looking right now at the about next combination: Hugo + Docsy + something like Disqus or integration with Confluence for runtime discussion about each chapter + integration with JIRA for tracking linked activity
-
Autogeneration of go code and pdf file was not implemented as a part of maven built process, because maven project is not the subject of demonstration and this action was performed only once.
-
I also have no idea what quality go code was generated from proto files.