To support vendor independent communication with common building management systems, two connec- tors (OPC DA and JDBC/SQL) were developed.

The Open Process Control (OPC) Data Access (DA) connector allows connecting to common building automation networks such as BACnet, KNX, M- Bus, ZigBee, as well as to many building manage- ment systems (BMS). All technologies which provide OPC DA Server software can be accessed by the connector. Since all OPC DA Servers provide the same Application program- mable Interface (API), uniform communication to different building networks is possible.

OPC DA supports registration for events (value changed, etc.) at datapoints. This allows to process building data streams in real-time.
Currently, the OPC Connector is implemented with the programming language Gamma, using the OPC Datahub (OPC Datahub 2012) environment.

Each project inherits from the ConnectorEngine. On startup, a DatapointOPC object is instantiated for each datapoint with an OPC data source defined in the MySQL database. Adaption of measurements within the Connector (e.g. to convert the measure- ment into a desired format) can be achieved by overwriting the transformValue() method.

Because of the limited adaption options and ven- dor lock risks caused by using the vendor specific environment OPC Datahub / Gamma scripting, a technology independent alternative is envisioned. Within the Google Summer of Code 2012 (GSOC 2012), a Java based OPC Connector (using the OPC DA library JEasyOPC 2012) will be developed.



The second connector allows communication with systems and read/write file formats, which are sup- ported by Java Database Connectivity (JDBC) com- patible drivers. It therefore enables data access to various databases (Oracle, Microsoft SQL, ODBC compliant databases, etc.) and popular file formats such as CSV, Excel, etc. based on the Structured Query Language (SQL). Due to technical limitations (the JDBC library is not notified when new data is added to the database/file), this connector supports data transfer by polling in a periodical manner only (i.e., every minute/hour/day/week/etc.). The JDBC Connector is implemented with the programming language Java.

The class Datapoint is a Data Abstract Object (DAO) of a datapoint in the MySQL database. The class DpConnectorJdbc implements the connector to any JDBC compatibe source. It automatically detects the table structure of the data source based on the information.

By probing the defined column names, appropri- ate SQL statements are generated. This enables sup- port for most common data source structures shown in Figure beside (a) and (b).

Support for additional data sources (e.g. proprie- tary systems) can be added by extending the class DpConnector and overwriting the method get- SourceData().

Since all communication of the presented connec- tors to existing building systems is based on Ethernet/IP, various installation setups are possible. For example, remote access to different building systems can be realized by using a Virtual Private Network (VPN).

By using an adaptive routing configuration on the VPN-GWs (e.g. OpenWrt 2012), infrastructure in- dependent plug and play installation is possible. For example, the VPN-GWs can scan for possible Inter- net connections (Ethernet/IP, WLAN, UMTS, etc.) and automatically connect to the best fitting one. Based on the VPN a secure communication to the monitoring server is guaranteed. By using watchdog scripts on the VPN-GWs, automatic reconnection in case of communication faults can reduce data loss and maintenance effort.

To store historical data, the relational database MySQL is used. The database logic is completely decoupled from client applications by using stored procedures for all kind of data access. It supports the processing of measurements by just “dropping” them in the database. Data storage rules optimize performance and disk usage based on deadband, sample interval, and minimal sample interval pa- rameters of each data point. Location management of physical sensors/actors and virtual data points is treated by logical grouping using zones. Based on the rich usage of stored procedures, performance and permission issues can be handled in a more fine- grained way than with direct access using SQL. It also allows a centralized implementation of data preprocessing algorithms. This can optimize data- query performance and prevents redundant code in different client applications (Matlab, Excel, Energy- Plus, etc.).

Using stored procedures for data-preprocessing allows different applications to access the measure- ments in a widely supported, simple, and uniform way. The processing application does not need to deal with the challenge of getting the measurements in the right format. Implementation details (Entity- Relationship Model, MySQL stored procedures, etc.) and performance benchmarks are explained in Zach et al. 2012.