theodi / bdns Goto Github PK

Suggestion: TRF

test

Governance document includes a number of TBAs:

• frequency of group meetings
• how quickly alternatives will be proposed to submitters
  etc.

These should be decided and documented in an update.

I'd like to suggest a new abbreviation for a DXC - DX Reversible Coil

There is an abbreviation DXCC for DX cooling coil, but it is quite common for DX coils to be reversible and both heating and/or cooling. I've used these on several projects before, and the application is po

Technically, when heating the coil is "condensing" rather than "DX", but DX seems to be the accepted name for any refrigerant system

Is there a way we can just simplify the below to something like 2 Gang and 1 gang Socket Outlet as ours are 13A here in the UK

And for floor box outlets if they contain data and power would this be covered under the floorbox Abbreviation?

  | outlet - double 20A duplex receptacle | DDR | IfcOutlet | POWEROUTLET
  | outlet - duplex outlets | DXO | IfcOutlet | POWEROUTLET

For buildings with Heat Interface Units HIU's between the landlord and tenant system mechanical systems what would we describe these as? These consist of a plate heat exchanger pump and valve.

Is it possible to introduce an "HIU" tag to describe these or give guidance as to what they should be named?
I cannot see a suitable mapping in the current published nametags list.

Blah blah

During webinar on 18 march, the need for a communication channel people can subscribe to was discussed. An initial idea of using the W3C Community Group's mailing-list is proving problematic, as it would typically involve joining the group, which is a legal hurdle for some.

Can we add the following proposals to the BDNS

AMP Amplifier
AVCP audiovisual control panel
AVCAM AV camera
AVWAP AV Wireless Access point
DSP Digital Sound Processor
DA Distribution Amplifier
PRO Projector
TPD Touch panel display
TX Transmitter
VC Video Conference
WP Wireless Presentation

Is this still correct? Components that are part of a devices are not considered to be standalone devices?

Originally posted by @richardkreid in #31 (comment)

The name syntax document is missing the image of the QR code

@DrOzakEsu commented in #4 about adding a multisensor abbreviation.
I've suggested to use MTS as the abbreviation for this. Any thoughts or comments?

Are there plans to include guidance for the optional prefix <COUNTRY>-<CITY>-<BUILDING>? For example should country follow the ISO 3166 codes.

When it comes to city and building it may be harder to recommended a convention as these become more region / organisation specific.

Feel free to close if this is outside of the scope of this project.

Suggest as SLS (Sound Level Sensor) within the ifc_class IfcSensor. It may be less common than other sensors but I could not find any alternative name in the existing list

sensor - sound level sensor,SLS,IfcSensor,SOUNDLEVELSENSOR

Allow for company name to be included within optional prefix for multi-tenancy buildings, so that there is no name clash to naming originating from different organisations.

Suggestion: STP

Room, floor, etc.

A GUID for each abbreviation could facilitate revision control.
Is this practical and useful?

The naming syntax makes mention of some attributes being mandatory (or _ as a minimum_) and others as optional.

• if this language reflects "common usage" we should make it clearer
• If this language reflects the fact that there is a full list of such attributes, with some being mandatory and other optional, then the document could list those, and make it clearer for systems implementing the syntax which properties they should expect/require.

Specific asset abbreviation - the list is too specific for some appliances and not inclusive for others. We have a global specification list we work with. It makes sense for us at least if we can group appliances by 'Type of Equipment' (column A) in order we can capture more products.

We propose the following

ANC | Ancillary
BEV | Beverage
COOK | Cooking
DISH | Dish Room
EQPT | Equipment
MISC | Miscellaneous
MOBL | Mobile Equipment
REFG | Refrigeration
SERV | Serving
STSL | Stainless Steel
VENT | Ventilation
WASTE | Waste Management

Hi All,

Have you considered standards for naming virtual points in addition to physical devices and I/O?

Could be valuable to provide guidelines for elements like:

• Setpoints: heating/cooling with deadband, duct static, hydronic pressure, etc
• Occupancy: from schedule, physical sensor, and optimal start/stop routine
• Calculated Values: enthalpy, PUE, EUI, WUE, environmental index, calls for heat/cool, calls for static reset, VFD fan tracking, etc
• Alarms: various levels for maintenance up to critical

Cheers,
Drew

Hi, we have some IoT sensors that need new abbreviations - would the below be ok?

• Indoor Air Quality - propose IAQ
• Outdoor Air Quality – propose OAQ
• People Counting – PCS
• Hot Tap point of use sensor – will use TPS
• E-ink display – propose EINKD
• Tinkerforge desk sensor- propose DESKS
• User Feedback Button – propose UFB

The abbreviations list has an abbreviation of LT. In the text, the example shows LTF. What is the best approach so that projects have a primary option and align?

@pisuke - for visibility.

Can we add an abbreviation for

Air Source Heat Pump - ASHP
Water Source Heat Pump: WSHP

It would be good to add a simple front matter paragraph to the documents. The governance doc suggests marking them as "Editors' draft" given the current phase of work.

Convert the asset_type column in the CSV file to lowercase

Have these devices I need abbreviations for

Water vending machine (VEND?)
Coffee Machines (VEND?)
White Noise Generator (WNG?)
Timeclock for clocking in (TMCLK?)

Bin level sensor - proposed BINS-
Leak sensor - proposed LEAKS-
Movement sensor (accelerometer based) - proposed MOVES-
Door contact sensor - proposed CONTS-

It would be useful to have an abbreviation for a Device Gateway.

The Device Gateway acts on behalf of the device(s) when communicating with a server. The device IDs of the child devices are still used and the Device Gateway is only there to facilitate communication and authentication.

There is a lighting - lighting gateway | LTGW already so would GW be good for a Device Gateway or something more specific?

Can speed gates be added to the abbreviations register?

SPDG would be our proposal.

Should we split the two main documents into their separate projects? This would allow for more accurate tagging of the issues.

An automatic pipeline for checking that abbreviations are not repeated.

We are looking to name and QR code Headend servers for Lighting and BMS systems.

Currently the nearest we can find that would fit this is HMI (Human Machine Interface) however this doesn't seem correct. Is this the correct tag to use or should we use another?

Hi,

While I can see a POE switch, and also a standard Ethernet switch in the list (POEETS and ETS) - what would be the recommended asset names for the below ICT devices?:

• Fibre switch
• Fibre and ethernet switch
• IP dongle for an intelligent PDU (e.g. https://www.austin-hughes.com/product/ipd-03-s/)

Thanks in advance,

John

Can we add an entry for an electric battery. BAT seems to be commonly used.

A QR code generation tool can facilitate creation of QR codes from a CSV or other structured data source.

It would be more useful to scope the names with a naming authority rather than location ie :

arup.com:ACU_001

rather than

UK-LON-8FS_ACU_001

The first is an an established methodology from urn/url naming and existing domains provide a ready way to implement this without additional discussion about naming conventions. Both approaches provide way to qualify the scope globally but using a location definition limits the activity of creating names to a single person/organisation/authority. It is much more useful and flexible to use authorities for scoping names as multiple actors can name objects that can then co-exist without risk of collisions. Location data is better provided by tag/metadata.

Hi everyone,

Could the following equipment be added please?

Many thanks

The syntax for device.name (and equivalent) specifies the use of alphabetic characters only, which may be appropriate but could also be biased towards a western approach, and cause us headaches down the line if this gets adopted in geographies typically using other writing systems (Arabic, Cyrillic, CJVK etc)

If we constrain to alphabetical now, allowing a broader character set later would probably break parsers.

Could we gather evidence of practice internationally, and understand whether the alphabetical constraint is reasonable, or whether there may be other sets of characters (from within Unicode) which may also be allowed.

Suggested MCS

Congrats putting together the first draft specification for the syntax. It is a clear and useful document, especially so for a first iteration.

If feedback from the industry on shape and scope of the draft is positive, I would suggest iterating on the document following guidance from a few resources created to ensure that the specification should be as easy as possible to implement consistently, therefore maximising the impact of the specification on interoperability.

The W3C Specifications guidelines may be a good starting point. It is a fairly comprehensive document with many recommendations, but the first I would suggest to focus first on the language and presentation of compliance:

1. review the introduction and flow of the document to make more explicit what types of things we expect to comply to this standard, and what compliance means to them. This will allow the specification to hold useful information both for producers of data (what is expected of the syntax) but also consumers of the syntax (e.g. how to deal with non-compliance)
2. Adopt compliance-focus language, e.g. from RFC 2119. I think the draft already includes some instances of the word shall, should, may and must: we should look at whether they are colloquial uses of the words, or whether they signal levels of compliance.
3. Distinguish (through prose or presentation) sections of the specification which are normative (substantial to compliance), and which are purely informational.

We will need an abbreviation for this Intelligent Switch Monitor Unit for the fire alarm systems. Could we please provide an update.
20004900_0001.pdf

Automatic heat and smoke vents are available commercially in two general categories. Concerning the scope of this effort, the mechanically opened vent, powered by springs, pneumatic actuator, or electric motors are of interest. The open/close state data point needs to attributed.

Should there be an abbreviation for automatic vents?

Note: we are aware of regional variations ie smoke extractor in Berlin.

Hello, I need new asset name abbreviations please. Here they are:

Grease traps, maybe GTP

Oil Water separator, maybe OWS

washer/dryer laundry appliance machines: we have 3 different types: standalone washers (WSH), standalone dryers (DRY), combo washer/dryer (WDS) that will need to be entered.

Please let me know if the asset abbreviations mentioned here will suffice. Thanks.

-Justin