[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] Proposed oBIX 2.0 Work Plan
Maybe so. It does offer the possibility of considerable conditional and combinatorial logic… We as a TC can start with 8 goals and vote it out after achieving 4…at this stage, it is best to get all goals and desiderata on the table. tc "If something is not worth doing, it`s not worth doing well " -- Peter Drucker
From: Bogen, Chris ERDC-RDE-ITL-MS [mailto:Chris.Bogen@erdc.dren.mil] I think the Reporting adn Aggregation piece may sufficiently address the need for the "alert logic" piece that I keep bringing up. It's probably more effective to keep it in the context of Reporting and Aggregation as not to dig too deep of a hole for ourselves. From: obix@lists.oasis-open.org [obix@lists.oasis-open.org] on behalf of Toby Considine [Toby.Considine@gmail.com] Based upon what I have heard in the last few meetings, oBIX 2.0 has the following work plan, and thereby an implied document structure. Work Plan for oBIX 2.0 The current work plan appears to be the development of advanced contract services to ride on top of the core services (1.x). All encodings and transport-specific information will be moved into specific documents to allow extensions and new work without revisiting the core specification. The specialized contracts, as of 20130317 are: Reporting and Aggregation (Historian) The historian does not scale well in its current form. A request for, say, a one year history on several sensors is larger and more unwieldy than it need be. It may be necessary to support variations such as projections. We do not want to break compatibility. Alarm Logic. This topic extends alarm contracts to include logic for alarms. If A happens followed within three minutes by B. If the cycle between occurrences of A is less than 5 minutes. This is in effect defining diagnostics with interactions between functions. If I am talking to 100 oBIX servers, I may want to apply that diagnostic to every AHU attached to each of them. Energy oBIX Servers are likely to participate in collaborative energy ecosystems including those managed by Energy Interoperation (OpenADR 2.0) or as described by ASHRAE SPC 201. This topic will define specific semantics and contracts to align with those defined for minimal conformance with BAESB REQ 2.1 (the Energy Services Provider Interface, ESPI) and map-able to Green Button. Potential contracts include not only energy usage reporting, but projections and contracts as well. We anticipate leveraging the existing OASIS Energy Market Information Exchange (EMIX) Specific information exchange requirements as defined in NAESB REQ Security Composition This topic introduces a role access mechanism into oBIX. oBIX 1.0 defines a monolithic model, all or nothing, for access to points and settings. This access should be limitable by role and by organization. We do not want to make a mandatory set of roles, or a mandatory framework, but instead define a means to apply notions of space (say a particular tenant) and of role to access to an oBIX server. We anticipate a means to discover the roles available on a server, to map those roles into a discoverable space, i.e. BIM. This topic includes addressing federated security, and may include how to apply SAML, XACML, and similar languages to oBIX servers Enterprise Scheduling Enterprise Scheduling applies the semantics of WS-Calendar to schedule interactions with building systems. This includes a notion of service oriented schedules instead of the control oriented schedules as today. (Example: Request room at temperature by 8:30 rather than Request room to begin heating at 8:10). This is likely to use the same semantic frameworks as security, i.e., to specify a room rather than a thermostat. As Enterprise scheduling moves toward a service semantics, it likely needs to develop some notion of quantity served. For example, if the enterprise shares that room 102 will be in use from 2-3:00 tomorrow, it conveys one sort of information. The enterprise system is likely to know whether 10 people or 30 people are involved, which may change pre-cooling and pre-ventilation requirements. BIM As BIM appears twice (Security, Scheduling), there may be a separate section on applying a BIM framework to oBIX. The BIM framework could then be referenced by the Schedule and Security portions. Conformance & Segmentation There is likely to be a Conformance section for each of the topics above as well as for oBIX Core (sic). “An application claiming conformance to oBIX Core must specify the version (1.0, 1.1, et al.) and meet the requirements for conformance with that specification” Did I miss anything? Are there other aspects that we want to cover? Please reply to the list. tc "Energy and persistence conquer all things." -- Benjamin Franklin
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]