Smart Buildings Technical Primer #199
Conversation
docs/tech_primer.md
Outdated
| - Proxied networked devices, e.g. BACnet/IP | ||
| - Proxied non-networked devices, e.g. RS485, DALI | ||
| - **Cloud-Cloud**: A device is managed by a third party who provides a cloud connector | ||
| - Approved third party managed service |
There was a problem hiding this comment.
"third party" and "managed" are not technical concepts so shouldn't be here. What is technically different about this that needs to be covered?
There was a problem hiding this comment.
The idea here is a device installed in a building which communicates over some proprietary protocol to a SaaS platform. This platform has an API to get data from the device. A connector may be written which reads/interacts from this API and publishes data over MQTT/UDMI. The connector may be running as a virtual machine somewhere. This means some of the physical aspects may not be applicable. I think the desire is UDMI is supported from devices, so this use case may be an exception and can be removed from this document
There was a problem hiding this comment.
Additional note - this may apply to VT/lift suppliers in future projects, or some IoT sensor products.
There was a problem hiding this comment.
So separate out the technical aspects (should be included) of what you said, with the administrative ones (should not be included). "Third party" is administrative, not technical. I think what you're describing is something like "external" -- which is indicating that the data source is external to the "confined" system. Or something like that that characterizes the architecture that you outline.
There was a problem hiding this comment.
I used the words **External** A device (on-prem or off-prem) consumes data from an external source and publishes it to Cloud IoT core
docs/tech_primer.md
Outdated
|
|
||
| ### Representation | ||
|
|
||
| How data is semantically represented |
There was a problem hiding this comment.
mmm -- not quite sure "semantically" fits here, there still is no meaning behind it. It's really something about how the data is incorporated into the data processing pipeline.
There was a problem hiding this comment.
"How devices are represented within different information sources"?
Reading it again it's more about the device (logical, reporting, virtual) rather than data?
There was a problem hiding this comment.
I think it's about "device relationships and how they are modeled"... ?
docs/tech_primer.md
Outdated
|
|
||
| How data is moved around on-prem | ||
|
|
||
| - **Analog**: The device uses an analog connection (1-10V, 4-20mA etc) |
There was a problem hiding this comment.
I think we should take out "Analog" for now. It's not reading right, and I think you're blending the line between what is considered a "device" here. Practically speaking, in the analog case the "device" is the thing with the ADC that's making it digital. It's not the same use of a "data moving around" as the other uses. I'd rather keep this clean for now and add it in later if it's necessary. Unless you have a clear articulation of why it's necessary to have this defined here -- but our goal is not to detail every kind of connection possible, rather the ones with salient meaning (e.g. people talk about "serial" devices all the time).
There was a problem hiding this comment.
I think it should be listed here because analog devices are a key part of building control and include things like actuators, temperature & flow sensors, smaller fans, etc. Although they are always connected to an ADC, which will either implement UDMI or connect over some serial interface to a gateway which does; I expect it to be common there are reporting devices which comprise only of points from multiple analog field devices, or represent a single analog field device. Therefore having the line in the tech primer makes it immediately clear that there is 'support' in UDMI for these sorts of devices.
In the industry the analog devices would be known as field devices, so the line could be A field device connected using an analog connection?
There was a problem hiding this comment.
What you're describing, tho, is something fundamentally different than the other things. You're talking about how to access a single point, while everything else is at a higher level (e.g. there's commonly the concept of an address or ID you have with serial and networked connections, but not so with analog). Practically speaking, I have never seen anybody discuss "analog" connections while doing a BOS design. Overall, UDMI doesn't expose things just because they're "industry standard" -- since that's rife with pain... rather, trying to focus on semantically what adds value to the concept. Can you give an example of a discussion where the concept of "analog" is relevant in the same context as talking about "UDMI"?
There was a problem hiding this comment.
All points true and I cannot give an example of a discussion where it's relevant in the same context as UDMI. I've removed it
docs/tech_primer.md
Outdated
| @@ -46,10 +53,12 @@ How data gets up into the cloud | |||
| - Bind & attach of proxied devices | |||
| - Encapsulation anti-pattern | |||
| - **Proxied**: A device that is not direct and is managed through a gateway. | |||
| - **External**: A device (on-prem or off-prem) consumes data from an external | |||
| source and publishes it to Cloud IoT core | |||
There was a problem hiding this comment.
take out the "and publishes it to Cloud IoT core" part -- once you're doing external stuff there are other paths of ingress. But, I thikn the "External" moniker still still apples.
docs/tech_primer.md
Outdated
| @@ -20,20 +20,27 @@ For the most part, this document addresses the scope of a Smart Ready building: | |||
|
|
|||
| ## Device | |||
|
|
|||
| Hardware that exists in the building that can change state in a way that can be machine communicated. A potentiometer or a flow switch is a device if it is monitored by a digital system. A commissioning valve or damper with no communication is not a device. | |||
| Hardware that exists in the building that can change state in a way that can be | |||
There was a problem hiding this comment.
This isn't quite accurate. A "device" is a logical entity that encapsulates a coordinated set of functionality. The problem is it's a very over-loaded term and so you can't say much in the way of definitions. Not all devices are hardware. Not all devices an be machine communicated (although it would be kinda pointless otherwise).
I'm not sure trying to define "device" will actually get you very far... which is why I jumped strait to the descriptive adjectives.
docs/tech_primer.md
Outdated
|
|
||
| ## Devices Classification | ||
|
|
||
| Various adjectives qualify the different flavors of a "device" found in a building. More than one can apply, and each has a specific technical meaning/definition (i.e. they are not subjective). | ||
| Various adjectives qualify the different flavors of a "device" found in a | ||
| building. More than one can apply, and each has a specific technical |
There was a problem hiding this comment.
"found in a building" ==> "present in the system"
No description provided.