Find JSRs
Submit this Search


Ad Banner
 
 
 
 
JSRs: Java Specification Requests
JSR 60: Building Automation Java API

This JSR has been Withdrawn
Reason: This JSR was originally proposed a long time ago, but failed to attract a critical mass for an expert group. After a few conference calls, the effort was abandoned.

Original Java Specification Request (JSR)
(Updated 2000.06.20)

Identification | Request | Contributions

Section 1. Identification

Submitting Participant: Tridium, Inc.

Name of Contact Person: Brian Frank

E-Mail Address: brian@tridium.com

Telephone Number: +1 804 527 3104

Fax Number: +1 804 747 5204

List of endorsers for this JSR: (Updated 2000.06.20)

Honeywell

Enron Corporation

Yamatake Corporation

Computer Process Controls, a Division of Emerson Electric Co.

EIB Association (EIBA)

Toshiba America

Toshiba Information and Industrial Systems and Services

Evantage, a Division of Virginia Power (Energy Services Group)

Strategic Solutions, a Division of Carolina Power & Light



Section 2: Request

2.1 Please describe the proposed Specification:

Today the building automation industry is embracing multiple open standards including:

  • BACnet
  • Lonworks
  • Internet standards (TCP/IP, HTTP, XML)
These standards do not, however, provide a complete solution for true open architectures. What is missing from the building automation suite of standards is a common software model.

This JSR is to develop a set of Java APIs which may be used to access and program building automation systems. The specification will include:

  • A Java based object model to define building automation software components
  • Definitions for common building automation applications (scheduling, alarming, trending)
  • Definitions for BACnet and Lonworks objects (devices, protocol stacks, and network management)

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The specification target is desktop and embedded Java platforms. The specification must take into consideration the constraints of embedded devices and solid state storage.

2.3 What need of the Java community will be addressed by the proposed specification?

Common Java APIs to program and access building automation systems.

2.4 Why isn't this need met by existing specifications?

No existing specification is targeted at the needs for interoperable building automation.

2.5 Please give a short description of the underlying technology or technologies:

The specification intends to define a Java model for the following technologies:

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Proposed package namespace is javax.baja

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

The APIs will take into account localization issues, and make use of the java.util.Locale and java.util.TimeZone classes.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.



Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The submitting participant has already developed a commercial product for building automation using the Java platform. The intention is to use the experience gained through this development effort towards publishing an open standard for the entire industry.

3.2 Explanation of how these items might be used as a starting point for the work.

This work has already been implemented in a successful commercial product.