 |
|
|
|
|
|
|
|
|
|
|
 |
 |
 |
 | |||||||
 | ||||||||||
 |
 |
 |
 |
 |
 |
 |
 | |||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |||||||
| ||||||||||
|
|
|
|
|
|
|
| |||
Modern day buildings contain vast amount of static and real time data. Static information such as building schematics are vital for security and rescue reasons. There is an increasing need for first responders to be instantly alerted of building alerts so that actions can be performed promptly [1]. Other features include the ability to remotely control building devices and processes. The Building Information Services and Control System (BISACS) is an infrastructure consisting of multiple computers and various software modules integrated together to accomplish specific goals.
Some of the goals for the BISACS include creating a mechanism to remotely access building information such as building schematics, creating a mechanism to be remotely notified of building alerts and creating a mechanism to remotely control a building's various devices. The following will describe the technology and mechanisms used in a computer based system to allow external users to be verified then logged into the system in order to gain access to building information such as its structural layout and/or to monitor a particular building or set of buildings for alerts. The "control" aspect of the BISACS is to allow external personnel to control certain essential devices located within a building. This aspect of the BISACS is currently under development. The basic mechanism for obtaining building information such as schematics is in place, however the actual data storage and retrieval process have not been implemented.
Presented here is the basic software infrastructure that has been developed as the building blocks to support the functions required for the BISACS project. So far, the alert notification and monitoring features of the BISACS have been implemented. The BISACS serves as a proof of concept showing how building information exchange and controls can be managed.
In order to reach the various goals for the BISACS, a user verification process and a data exchange process must be established. For the user verification process, a server was created to validate electronic x509 certificates via a socket port. A web services interface was created to support user identification and password verification. For data exchange, another web service interface was created to be generic enough for bidirectional data exchange such that alerts can be broadcast out of the building while commands can be sent into the building to control devices or processes. Using standard web interfaces via browsers, a mechanism for monitoring alerts for a network of buildings can be demonstrated. The technical aspects of how these processes work as well as how the alert monitoring mechanism works are discussed below.
In order to understand the interaction between the components of the BISACS, the basic building blocks that have been implemented will first be described in order to demonstrate how everything will fit together in creating the final system. Basic building blocks such as the user verification process, the data exchange process and the protocol used for the data exchange will be discussed first before the bigger components of the BISACS will be described in order to arrive at how the system is integrated.
The user verification process involves authenticating the user as well as authorizing user privileges along with authenticating an official certificate of authenticity (i.e. an electronic digital certificate). The authentication part of the user verification process requires verifying the user's identifier and password along with verifying a certificate of authenticity. The authorization part of the user verification process supplies the user's access privileges for the system and currently has not been implemented. All parts of the user verification process will be supported by the BISACS [2].
The certificate authentication process involves developing a server (i.e. the Certificate Validator) to validate clients' certificates. This process is summarized as shown in the flow diagram below:
Once the certificate authentication process is successful, the client has to go through the user authentication process in order to log into the system. The user authentication process involves developing a web services interface that validates the client's user identification and password against a data store containing all valid users. This process is summarized as shown in the flow diagram below:
The BisacsPrimaryPortal web services end point is created with a couple of generic interfaces that processes either a string or an array of strings as the input and return an array of strings for their results. These interfaces are generic enough to handle outgoing data exchanges as well as incoming commands and requests. The following flow diagram describes the interaction for the web services interfaces [2]:
The BISACS utilizes a network of web application servers to acquire and store alerts. At the lowest level is the BISACS Base Server (BBS), it supports web services interfaces for accepting and relaying alert notifications. These alert notifications are sent to the BBS either from the devices directly or from a Services Interface (SI) component acting on behalf of the devices. The Services Interface components have the intelligence to communicate with the BBS web services interfaces and can therefore hide all low level device specificity. Alert notifications are relayed to other nodes by active clients polling the BBS for its information. Residing above the BBS are the BISACS Proxy Servers (BPS). Currently, the BPS supports polling for alert notifications and relaying alert notification to other nodes. The BPS can monitor one or more BBS as well as other BPS nodes, this hierarchy allows for a robust network of servers that can monitor a large area for alerts. The BPS nodes are designed to be the node of choice for monitoring stations such as for building managers and first responders operation centers. The BISACS network hierarchy is designed to be robust and scalable enough to allow for coverage of alerts of any kind from as large an area as required. Currently, alerts are being relayed from all nodes using the OASIS Common Alerting Protocol v1.1 [3]. The diagram below demonstrates how a BISACS network might be configured, the key thing to observe is how the BPS can be configured to monitor one or more nodes below it. Support for processing commands via the BBS from remote work stations are in the plans for future implementation.
The following diagram shows an overview of how various components within the BISACS are integrated. The BBS accepts alerts while the BPS monitors alerts. Operation centers are dependent on the BPS to gather all pertinent alerts. For building implementations, Services Interfaces such as SNSI & BSI can be protected behind a firewall and the BBS shall act as the gateway to their information as well as for supporting the execution of external requests or commands destined for devices controlled by those Services Interfaces (future goal).
Communication with the BBS and the BPS is done via web services interfaces. The Services Interfaces (SI) that reside behind the firewall such as the Sensor Network Services Interface (SNSI) and the BACnet Services Interface (BSI) also make use of web services interfaces to accept requests or commands (see the above diagram) [2].
All outgoing alerts travel from the BBS nodes to other BPS nodes, but all incoming requests or commands destined for a specific device must go through the BBS that has access and control over that device. The user verification process may be configured to pass through the BPS node, but ultimately the user verication process checks the data store at the BBS node (refer to the diagram below).
All communication with any of the BISACS nodes are done using TLS encryption. Encrypted tokens will be used to validate accessibility to the BISACS web services interfaces, i.e. without a valid token, the BISACS web services interfaces will not respond to requests or commands (future goal).
To access the data from a BBS or BPS, a sample web client was developed. The login screen for the BISACS can be reached by using any web browser. Notice that the address is a secured address using TLS. Currently, only user identification and password combinations are used to authenticate the user when using the web client. Future access restrictions to the BISACS web client may be applied by creating an access list of known IP addresses for certified work stations such that all unrecognized IP addresses will not be allowed in to the BISACS web client. For sending requests and commands to the BISACS, an application specific client will be used so that certificate authentication can be done (future goal).
If an incorrect user identifier or password is entered, an error message will be displayed as shown in the screen below:
After the user is authenticated, the options screen is displayed. The "Alert Status" option allows the user to monitor alerts that are present in the server's database. The "Alert Filters" option allows the user to do content filtering on the data contained in the Common Alerting Protocol messages.
A sample of the Common Alerting Protocol (CAP) message that is passed from node to node within the BISACS network is shown below. The filter mechanisms filter on the contents of these CAP messages.
The filter options screen allows the user to filter on a select set of data from the Common Alerting Protocol messages. The "Event text" filter allows the user to filter on sub-categories (the "event" sub-element of the "info" element is used for specifying sub-categories in the CAP message). The "Description text" filter allows the user to filter on the text within the CAP messages' descriptions. The 12 message categories can be filtered on by selectin "Yes" or "No", where "Yes" indicates to the system to look for that particular category or categories if more than one categories are set to "Yes". Note that if all category filters are set to "No", then no filtering is done for any of the categories, i.e. all categories will be accepted. The "Poll interval" parameter allows the user to indicate to the system how often the web client should poll the server(s) for alert information; these time units are based in seconds between 2 and 60 seconds. Using the value of -1 tells the system to poll the server(s) only once. The rest of the filters allow the user to select valid values pertaining to each filter. If the value "All" is chosen, then all values are allowed for that particular filter [2].
Choosing the "Alert Status" option takes the user to the "Alert Status Screen". The screen below shows that there are no alerts in the server's database. The filter parameters are indicated at the bottom of the screen.
The diagram below represents a user monitoring alerts while logged into a BISACS Base Server (BBS).
The "Alert Status Screen" below represents a user monitoring alerts while logged into a BISACS Base Server (BBS). The "Urgency Color Code" table is present as a reference to indicate to the user what the urgency level the alerts fall under.
The diagram below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that resides 1 level above a BBS.
The "Alert Status Screen" below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that resides one level above a BBS (see above diagram). Notice that the "Alert ID" field has the alert identifier with the character '@' separating the name of the server that sent the alert.
The diagram below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that monitors alerts from 2 levels above a BBS and also 1 level above another BBS,
The "Alert Status Screen" below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that monitors alerts from 2 levels above a BBS and also 1 level above another BBS. Notice that the "Alert ID" fields show the alert identifiers with the character '@' separating the names of all of the servers that those alerts hopped through to get to the current level in the network hierarchy; i.e. some of those alerts went from node "seurat.cbt.nist.gov" (BBS2) to node "p623572.campus.nist.gov" (BPS2) to the current BPS node (BPS1) that is at level 2. For this example, notice that BBS1 is also "seurat.cbt.nist.gov".
The diagram below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that monitors alerts from 2 Base Servers.
The "Alert Status Screen" below represents a user monitoring alerts while logged into a BISACS Proxy Server (BPS) that monitors alerts from 2 Base Servers.
By clicking on the alert identifier field, the user will bring up a window showing more details about that particular alert. Notice that this screen has two links; the "Alert location" link will display a building's floor plan of where the device that initiated the alert resides (if available). The "Sent from server" link will bring up the login screen for the BBS that the alert came from (i.e. the originating server that sent the alert).
The screen below shows a sample floor plan and location of the device that sent the alert if the "Alert location" link was clicked. Notice that the "Alert Location Screen" also contains a "Sent from server" link allowing the user to log into the BBS that sent that alert.
With the underlying software framework in place supporting certificate authentication, user validation, and information exchange for the BISACS, future goals for the BISACS may include but not limited to the following:
1) Support the communication process with sensors and devices to obtain real time status information such as active/inactive status and/or various information those devices have to offer.
2) Develop a mechanism to remotely store and retrieve building information such as building schematics and building information models (BIM).
3) Develop a mechanism to remotely execute or forward commands to various devices within a building such as a switch or valve.
4) Develop a mechanism for using a key or token so that only verified users will be allowed to access the BisacsPrimaryPortal web services, i.e. so that a user can not use his own software to communicate with the BisacsPrimaryPortal directly without going through the user verification process. This key or token can only be obtained once the user verification process is successful.
Various Open Source projects were used in developing the BISACS. Software
packages that were involved with developing and supporting the BISACS included
but not limited to the following:
- The Apache Tomcat Project was used
as the Application Server for hosting the BISACS applications.
http://tomcat.apache.org/
- The Eclipse extensible development platform was used as the Integrated
Development Environment (IDE) for developing the Java code used by the BISACS.
http://www.eclipse.org/
- The Eclipse Web Tools Platform (WTP) project was used for developing
Web Services Interfaces and for publishing Web Services.
http://www.eclipse.org/webtools/
- The Apache Axis Project was used to handle all Simple Object Access
Protocol (SOAP) communication.
http://ws.apache.org/axis/
- Sun's Java Development Kit (JDK) and Java Runtime Environment (JRE)
were used for developing and testing the BISACS.
http://java.sun.com/
- The Apache jUDDI Project was used as the Universal Description, Discovery, and
Integration (UDDI) registry server.
http://ws.apache.org/juddi/
- MySql was used as the Database Management System (DBMS) for the BISACS.
http://dev.mysql.com/
1) Holmberg, David G., Davis, William D., Treado, Stephen J., Reed, Kent A., "Building Tactical Information System for Public Safety Officials, Intelligent Building Response (iBR)", NIST Internal Report 7314, January, 2006.
2) Vinh, Alan B., "Building Information Services And Control System (BISACS): Technical Documentation, Revision 1.0", NIST Internal Report XXXX, July, 2007.
3) OASIS Common Alerting Protocol v1.1.
This software was developed at the National Institute of Standards and Technology by employees of the Federal Government in the course of their official duties. Pursuant to Title 17 Section 105 of the United States Code this software is not subject to copyright protection and is in the public domain. This software is an experimental system. NIST assumes no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic. We would appreciate acknowledgement if the software is used.
This software can be redistributed and/or modified freely provided that any derivative works bear some notice that they are derived from it, and any modified versions bear some notice that they have been modified.
By selecting many of the links above, you will be leaving NIST webspace. We have provided these links to other web sites because they may have information that would be of interest to you. No inferences should be drawn on account of other sites being referenced, or not, from this page. There may be other web sites that are more appropriate for your purpose. NIST does not necessarily endorse the views expressed, or concur with the facts presented on these sites. Further, NIST does not endorse any commercial products that may be mentioned on these sites.
|
Privacy
Statement / Security Notice | Disclaimer |
FOIA | Inquiries
Date created: September 20, 2006 |
 |