AutomatedBuildings.com Article - Servers Which Serve

Cimetrics has a keen interest in building automation servers or any data servers which serve their data “well”. To us, to serve data well means to serve the needs of multiple different clients, each with different uses case, all at the same time.

Our primary concerns are about how well the device data stream can be delivered to an enterprise system. Our specific enterprise system is Metermetrics, but we are trying to envision the breadth of having a couple of operator workstations, maybe a point survey tool, and perhaps a historian - all getting data streams, possibly co-temporally (as we mention elsewhere), for about one hundred automation devices (mostly meters).

•    State machine model of the actual device function.
•    Configuration model.
•    Data and network delivery model.

We are not interested in device internal mechanisms, as much as they are abstracted from the enterprise data exchange. Our interest boils down to data and network model if one assumes the devices have excellent defaults and have been pre-configured or simply end-user configured. Most of the time a device’s internal state machine is not at issue.

Data and network delivery gets one into issues of protocol. TCP/IP protocols are our favorites for data exchange in the widest possible venue. Things like REST and XML have great generality and can be augmented and wrapped to address concerns about security, availability, semantics and so on.

But we understand the need for easy low cost multi-drop serial for tiny end point sensors and devices – which leads to RS485. We particularly like BACnet, but also work with Modbus. Both BACnet and Modbus have good delivery breadth from serial all the way to TCP/IP. We like OPC, SNMP, REST and other TCP/IP general protocols, particularly those centered on XML with overlaid schema.

Most of our server issues are actually not issues with regard to specific protocol standard compliance. The issues are more about good cooperative/enterprise practice and citizenship and keeping problems from cropping up in (automatic) data consumption.

Assertions herein are made with the assumption that an enterprise system (not necessarily a human) and an operator workstation (not necessarily a human) and a human will have to cope with any issue in parallel. An unambiguous solution is called for in such a case, not a multitude of options. Bear in mind again that the concerns are not so much about protocols standard adherence though we will mention issues that we have with that, too, in as much as it is a factor along the way to getting to a data stream delivered.

We like the server to be clearly identified via network:
Make, model, vendor should be easy to find. Description and location information are important. The server should have a clear and fixed list of objects to portray its data. The names of the objects should be clear and descriptive like Temperature-Input-Duct-4 (NOT names like AV-120). Periods, commas and spaces in object/device names are problematic. Common separators will interact poorly in enterprise databases and spreadsheets – often being the default decimal place and record delineation. Descriptions should be clear, whether in a manual or contained in objects.

Units should be well defined and interact well with the spirit of the protocol they are embedded within. This varies. Modbus has no concept of units and they must be conveyed in allied documentation. But it is important for such a system that units do not suddenly change out from underneath the client. Bear in mind the overriding mandate of multiple possible enterprise clients. A server should have a clear and relatively unchanging opinion of what it delivers and not be pulled this way and that by different clients.

BACnet is object oriented and does a good job of keeping things clear, but some servers go astray. Proprietary units and properties are some of those ways. Proprietary engineering units are problematic. These should be avoided for good multi-client enterprise exchange. It is not that they should be disallowed. It is simply that proprietary units often arrive in a device due to unintended consequences of pre-configuration process (except for some devices which simple have sets of objects with all proprietary units where the builder did not even go to the trouble of trying to be transparent to a wide set of clients and/or flexible for said clients). The proprietary units should be avoided in the following way:

In any pre-configuration discourse (form, discussion, spreadsheet) the specifying entity (for use by cooperating end consumer clients) should be warned that their units/measure selection will result in a proprietary unit (potentially non-interoperable in target end case enterprise database uses), and options should be suggested which result in standard units.

BACnet has not covered all units. BACnet covers almost all reasonable physical deliverables (including things like currency) in both SI and imperial measures (and even a few others where the domain warrants), but it cannot cover everything. Some domains want to have their “unit” include something about assumptions about the nature/quality of the deliverable. Some examples of this are apparent and reactive energy, shaft versus consumed horsepower, and gauge versus absolute pressure. Units are units. They describe the nature of conformance to the dimensions of the physical universe, and the assumptions about qualities should reside in descriptions.

Issues of nomenclature have some that prefer litres and others that prefer milli-cubic-meters. Both are valid SI. The answer here is to accept what BACnet (and the world) has done as imperfect and go with what exists and is close enough.

Issues of conformance magnitude or nomenclature arise. One “mode” of units might use litres and another mode might use cubic meters. Some like W versus kW versus MW. There are clear size differences here, but luckily BACnet analog values and objects in OPC and XML are generally floating points and can go through the range with their exponent. Enterprise databases are comfortable with the floating point exponent model.

Again first look to what standard TCP/IP object oriented protocols have provided and what enterprise databases accept. Keep also in mind that a diversity of client opinion might exist. Collection systems have no preference beyond this and treat all as equal. The designer can expose preferences - like taking the “shortest string” or “least unit prefixes” approaches - in descriptions… Nuances are up to the designer in their domain. But a device should have a fixed and forever opinion/default in its basics. The domain does not change over night at a site, and so the units range should not change overnight.

This issue of firmness is not about pushing decisions/opinions on a domain. But it is about the enterprise (and myriad clients) demanding of the device that it not be lukewarm on the matter of what units/representations are best. It is about a device doing the best it can in an imperfect world to firmly meet the needs of enterprise collection and monitoring systems. In short, when designing a device, keep the needs of multiple enterprise clients in mind.

Breadth of data is important to enterprise systems. Let us concentrate on meters.
For example we like to make sure that the following are included in meter sensors:
- Flow
- Consumption
- Time average of flow (Demand)
- Quality or qualities of the flow (temperatures and pressures for fluids, for electric this might include phase variation, harmonic distortion, and other variances)

Some meters are multi-channel - think phase in electric and fast/slow in some sorts of two stage meter. Such should have all above for each stage/channel. Some meters do directional binning (delivered and received). Some meters do time domain binning (time-of-use, TOU, periods). Such should have all above for each bin. Some meters have bin/stage/channel aspects and can be considered separate meters and treated (reasonably) as totally separate and disjoint devices. But there are cases where inter channel bin/channel (or external) interactions are also being metered, e.g. for inter-leakage (say ground current) or phase (where intrinsically what is being measured is a relation between channels).

[an error occurred while processing this directive] Roughly, from the above, a meter should have about zero to five base parameters and then about five to ten parameters per channel bin. An average meter (as much as there is such a thing) has about two to four bins. This suggests that a meter has about ten to forty parameters of interest depending on how many bins/channels/phases it has.

Networking constructs sometimes deserve note in end devices. Method of discovery enablement and broadcast redirection (BBMD and FD in BACnet) are useful on TCP/IP networks. Devices which are actually a collection of internal virtual devices (possible under a BACnet physical layer – even MSTP and PTP) must have good defaults for network settings and ways to make clear the import of these settings to end-users. For OPC and XML this must be layered in auxiliary discovery services.

Multi-client access sequencing is key. It is not a good idea to allow configuration of a device via the channel the enterprise uses to extract data, but given that almost all enterprise system clients will not attempt to write configuration to their own ends (they are expecting another supervisory system to act in parallel in that role) then we can be agnostic on this. Assume the clients will not come single file and that there might be eight of them asking for data at any given instant. A device may choose to sequence or defer responses, but it should avoid ignoring or dropping requests.

Overall, if you have to take away a single concept, think of the enterprise which a server serves, not as a single client, but as an aggregation of clients with different needs and goals; clients who all would like direct access to the data flows; clients who are willing to be hands off on configuration, but also expect the same from all others; clients who cooperate to get the most from their servers’ services; clients who expect their use cases to be met, and for the servers to serve.

Albert Putnam is responsible for Cimetrics’ BACnet router and gateway product lines and the automation systems integration group. He manages a team of engineers, technicians, and subcontractors working in support of systems integration. Putnam has extensive experience in network systems development and information collection and conversion. He has background in physics, mathematics, modeling and analysis, and practical experience in cryogenic engineering, microwave technology, and computer electronics. Putnam has had extensive engagement in project and product development. He has managed small teams doing engineering work on various projects since 1985. Since joining Cimetrics in 1997, he has managed a team of engineers in Kazan, Russia, doing both hardware and software embedded systems engineering. He was president of the Canadian Association at Cornell in 1995 and an Autodesk liaison at Cornell from 1994 to 1997. Putnam graduated with distinction from Dalhousie University in Nova Scotia in 1988 and pursued graduate degrees in Physics at Cornell University. His Ph.D. dissertation topic was "Magneto-Dynamic Properties of Dilute Solutions of 3He in 4He at Low Temperatures in High Magnetic Fields.” Putnam is a member of the American Physical Society and the Association of Energy Engineers.

[an error occurred while processing this directive]
[Click Banner To Learn More]

Events	Want Ads
Our Sponsors	Resources