-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Smart Buildings Technical Primer #199
Merged
Merged
Changes from 10 commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
331dd84
WIP
noursaidi f08d94d
WIP
noursaidi d89391a
general changes
noursaidi 16cfc28
bold is double asterick
noursaidi 880a150
fix broken links
noursaidi 0c2abc8
resolve some comments
noursaidi d93039c
comments
noursaidi f031c75
address comments
noursaidi b1dc761
semantic representation
noursaidi 9424fd4
removed semantics
noursaidi 9710da5
resovle comments and fix line length
noursaidi f5408c0
address comments
noursaidi File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,135 @@ | ||
# Smart-Ready Building Technical Primer | ||
|
||
This document provides primer for smart-ready building assembly, to essentially | ||
answer the question *"What does Smart Ready mean?"* and *"How do we know it to be | ||
true?"* Specifically, it addresses the delta between a traditional site and | ||
smart-ready sites: places where new bleeding edge building technology is being | ||
used. | ||
|
||
# Key Terms & Definitions | ||
|
||
## Building Models | ||
|
||
There are different levels of "digital maturity" for different buildings. Each | ||
one has a slightly different scope in terms of what it means to be "complete." | ||
For the most part, this document addresses the scope of a Smart Ready building: | ||
- **Legacy**: It works, but does not meet requirements or guidelines. | ||
- **Compliant**: Meets basic security and networking requirements. | ||
- **Smart Ready**: On-prem integrated with the cloud using UDMI & DBO. | ||
- **Digital Building**: Completely integrated with back-end services. | ||
|
||
## 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. | ||
|
||
## 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). | ||
|
||
### Connectivity | ||
|
||
How data is moved around on-prem | ||
|
||
- **Analog**: The device uses an analog connection (1-10V, 4-20mA etc) | ||
- **Serial**: The device does not have an IP address, rather uses a wired serial connection. | ||
- **Networked**: The device has its own IP address and presence on the wired or wireless IP network. | ||
- **Bridged**: The device is on an isolated wired or wireless network behind a gateway device that is networked. | ||
|
||
### Ingestion | ||
|
||
How data gets up into the cloud | ||
|
||
- **Direct**: Maintains an authenticated connection directly to Cloud IoT Core. | ||
- Must be networked | ||
- Has a unique private auth key | ||
- **Gateway**: A direct device that manages data for other proxied devices. | ||
- Bind & attach of proxied devices | ||
- Encapsulation anti-pattern | ||
- **Proxied**: A device that is not direct and is managed through a gateway. | ||
|
||
### Representation | ||
|
||
How devices are represented within different information sources | ||
|
||
- **Reporting**: Has an entry in Cloud IoT Core and reports telemetry data. | ||
- Reporting connected devices | ||
- Reporting proxied devices | ||
- **Logical**: Has a semantic representation in the site building config. | ||
- **Virtual**: Logical-but-not-reporting. | ||
|
||
## Information Sources | ||
|
||
- **Qualification Summary** - One for each type of networked device | ||
- **Digital Building Device Register** - Comprehensive list of all devices on a project | ||
- **Site Model** - Any ingestion device (direct, gateway, or proxy) | ||
- **Building Config** - Does omit networked devices that don't report | ||
|
||
## Cloud IoT Core Definitions | ||
|
||
- Project | ||
- Administrative domain (user auth and billing) | ||
- Can contain multiple registries (buildings) | ||
- Registry | ||
- Not the same as the Digital Building Device Register | ||
- One Registry per building site (one site_model, one building config) | ||
- Device | ||
- May be direct or proxied | ||
- Maps to a reporting device | ||
- Gateway | ||
- Proxies for non-authenticating devices | ||
- Represented in Site Model, but maybe not Building Config | ||
|
||
|
||
# Base Tools & Capabilities | ||
|
||
## Device Qualification | ||
|
||
[Device qualification](https://github.com/faucetsdn/daq/blob/master/docs/qualification.md) | ||
qualifies device types as meeting a baseline connectivity and security | ||
requirement by performing a series of predefined tests against a device. | ||
|
||
### Prerequisites | ||
|
||
* Devices are available for qualification | ||
* [DAQ tool](https://github.com/faucetsdn/daq/) set up for use | ||
|
||
### Verification | ||
|
||
grafnu marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* Device qualification configuration and reports for the device available. | ||
|
||
## Managed Network | ||
|
||
### Prerequisites | ||
* Digital building registry is provided | ||
|
||
### Verification | ||
* ATA validates on-network configuration | ||
|
||
## Device Management | ||
|
||
All devices which are _smart ready_ are required to support | ||
[UDMI](../../README.md). For guidance on what compliance with the UDMI schema | ||
means, refer to [compliance documentation](compliance.md) | ||
|
||
### Prerequisites | ||
|
||
* [site model](site_model.md) provided and all devices registered into GCP | ||
* devices are setup in a qualified configuration | ||
|
||
### Verification | ||
|
||
* [registrar](registrar.md) and [device telemetry validations](validator.md) are clean | ||
|
||
## Digital Buildings Ontology | ||
|
||
Points and device naming is required to abide by | ||
[Digital Buildings Ontology (DBO)](https://github.com/google/digitalbuildings) | ||
|
||
### Prerequisites | ||
|
||
* [Building Config](https://github.com/google/digitalbuildings/blob/master/ontology/docs/building_config.md) file provided for site | ||
|
||
### Verification | ||
|
||
* building config passes | ||
[DBO validation tools](https://github.com/google/digitalbuildings/tree/master/tools/validators) |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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