Building-in-Briefcase: A Rapidly-Deployable Environmental Sensor Suite for the Smart Building

A building’s environment has profound influence on occupant comfort and health. Continuous monitoring of building occupancy and environment is essential to fault detection, intelligent control, and building commissioning. Though many solutions for environmental measuring based on wireless sensor networks exist, they are not easily accessible to households and building owners who may lack time or technical expertise needed to set up a system and get quick and detailed overview of environmental conditions. Building-in-Briefcase (BiB) is a portable sensor network platform that is trivially easy to deploy in any building environment. Once the sensors are distributed, the environmental data is collected and communicated to the BiB router via the Transmission Control Protocol/Internet Protocol (TCP/IP) and WiFi technology, which then forwards the data to the central database securely over the internet through a 3G radio. The user, with minimal effort, can access the aggregated data and visualize the trends in real time on the BiB web portal. Paramount to the adoption and continued operation of an indoor sensing platform is battery lifetime. This design has achieved a multi-year lifespan by careful selection of components, an efficient binary communications protocol and data compression. Our BiB sensor is capable of collecting a rich set of environmental parameters, and is expandable to measure others, such as CO2. This paper describes the power characteristics of BiB sensors and their occupancy estimation and activity recognition functionality. We have demonstrated large-scale deployment of BiB throughout Singapore. Our vision is that, by monitoring thousands of buildings through BiB, it would provide ample research opportunities and opportunities to identify ways to improve the building environment and energy efficiency.


Introduction
Indoor environment monitoring and control plays an important role in the operation of a building. One main goal of buildings is to ensure the safety and comfort of the occupants. A recent focus has been on minimizing energy consumption without compromising these goals [1]. Tailoring services such as Heating, Ventilation, and Air Conditioning (HVAC), lighting, and electrical power has the potential to save a significant amount of energy consumed [2]. HVAC and lighting respectively comprise 48% and 22% of the total energy use of buildings in the USA. In addition to environmental awareness, occupant-aware control schemes have been shown to save between 10-42%, depending on factors such as outdoor climate and control strategy [3,4]. Having a more detailed view of building environment and its occupants opens the door to more energy savings as well as building services that are tailored to specific purposes and target groups.

System Architecture
There are three main components involved in measuring, communicating, and storing the environmental readings: BiB sensor devices, local wireless router, and central database server. Figure 3 illustrates how these agents are connected, as well as the relevant internal components of the local wireless router. The BiB sensors, which will be described in depth in Section 4, connect to the wireless router using standard wireless 802.11 b/g secured with WPA2. Figure 3. System architecture overview. The BiB sensors communicate with the WiFi router through TCP/IP 802.11 protocol. The data is forwarded to the PI server by the 3G Modem that allows operation even without internet access infrastructure.

Wireless Router
The purpose of developing a self-sufficient local server is to support the idea of a "building in briefcase" sensor suite, where a sensor network can be rapidly deployed to initiate long-term monitoring, without the need for external infrastructure. Our latest solution is an off the shelf TP-Link wireless router running a custom configured OpenWrt build and custom Python processes. This combination of off the shelf hardware, customized OS build and custom code facilitates the following: • Low power consumption and voltage of the router allows for short-term operation on portable lithium-ion batteries or longer term on solar power.

•
Small size and no moving parts allow for the most flexibility in placement to optimize range and minimize obtrusiveness.

•
Push-button simplicity. While a web-based configuration UI exists, a simple on/switch is the only interface we expect an end user to interact with.
• Extensibility. The availability of two built in USB ports allow for the addition of large quantities of local storage and choices for WAN connectivity.
OpenWrt and ROOter. OpenWrt is based upon the Linux kernel and primary used on embedded devices for routing network traffic. There are numerous optional software packages that can be added to the base OpenWrt distribution and it is straightforward to add additional components as needed. The modifications to enable 3G modem communication were carried out as described by the ROOter community. Additional configuration was made to enable a USB flash drive to be supported and mounted as a Linux file system. Since we planned to use Python as the primary language for custom code on the router, we configured our OpenWrt build to include the full Python 2.7 language environment. Paramiko is a module that implements the SSH2 protocol for encrypted and authenticated communications with remote machines.
Python Socket Listener. The first custom Python process acts as the listener and socket handler for incoming connections from the BiB sensors. Upon the establishment of a client socket connection, data is read from the socket and decoded based upon our custom recordstore protocol described later. The decoded data is immediately written to a flat file on the USB Flash drive. Because we have our sensors configured to buffer data in memory and transmit only every 10 min, upon receipt of this accumulation of data, the process writes this single connection to a file.
Python File Distributor. The second custom Python process polls the specified directories on the USB flash drive for unsent files. Any unsent files are batched for multiple sequential puts across a secure File Transfer Protocol (sFTP) connection made to the Database Server. Upon the successful sending of a file to the Database server, the file is renamed to indicate its sent status. To maintain space, but also provide for some data backup, after a configurable number of days have passed (currently 10 days), a day's specific directory and contained files are removed.

Database Server
The central database server is a single server designed to receive and store the data collected by all of our BiB sensor networks. Maintaining all the collected data in a single repository allows for simplified data management and easy comparative analysis of collected data across all our deployment sites. To fulfill this need, we needed a database server and software that provides: • High availability and solid stability. As a central component in the entire system, downtime or instability of this component would affect all sites at which a BiB sensor network was deployed and could not be tolerated. • Scalability. While initial experiments involved two BiB networks with 6-10 sensors each, if the solution is deployed to hundreds or thousands of sites, we did not want to re-architect the backend solution. • Efficient handling of time series data. With potentially thousands of sensors collecting data every second, we need a storage solution that can intelligently store meaningful data while discarding noisy or redundant data. This has been addressed by only keeping the change points in the time series and performing necessary sanity checks for data points before storage.
PI System. The PI System is highly optimized to handle large quantities of time-series data while minimizing disk usage. It does this through configurable filters that allow noise below a given reading's typical margin of error as well as compression based upon a swinging door algorithm. This flexibility allows us to maintain high sample rates without requiring unmanageable amounts of physical storage.
sFTP server. In order to get the data onto the Database Server, we are currently running the SolarWinds free sFTP server, which receives the incoming sFTP connections from the BiB routers and handles authentication and encryption. The sFTP process simply outputs the sent files into a specified directory.

Data Visualization
The overall objective of the BiB project is to be able to view and analyze collected data to gain insight into building system and occupant behavior. Our goals for the basic data access were simple: provide easy to access end-user customizable graphing and raw data access with a robust security model to address concerns of data privacy (Figure 4). The left panel is organized in a structure from briefcase, to individual sensors, and to sensor measurements. User can only access the information with the given privilege. The right panel is a visualization of time series measurements, which can be arbitrarily zoom-in/out and overlay a list of measurements to compare the trends. The user simply needs to drag the corresponding sensor measurements in the left panel into the right to view the data in real time.

Communication Protocol
The communication protocol between the BiB sensor and Wireless router was custom built with several design goals. The protocol should be computationally simple allowing a microcontroller to process with minimal power. The protocol needs to be extensible but not overly complicated. It should support batching multiple readings into a larger packet sent at a frequency less than the sample frequency.

Lower Layer Considerations
The goal was not, however, to write an entire network protocol stack from the ground up so we take advantage of TCP/IP and its guarantees of reliable transmission. The TCP/IP stack extensively uses acknowledgement packets to validate the successful transmission of data, which is important to ensure that our sensor data is not lost, since we can later re-send the data if a transmission failed.
While TCP is chosen for its built-in mechanisms to ensure that data reliably reaches the server, this comes with a major drawback. Since TCP relies on many separate control packets to establish and tear down a connection, this requires that the radio to be active for the entire time. Thus, approximately one third of the sensor's battery life is expended by the radio alone, even at a very infrequent reporting rate. Future work will be to use the UDP protocol for which packet reliability is not enforced by the protocol. We can add a custom acknowledgment method that requires less overhead than TCP.

Message Framing and Description
Since TCP is a stream-oriented protocol, it guarantees that bytes are delivered reliably and in order (otherwise delivering an error). However, TCP does not provide framing utilities to designate discrete sets of bytes that should be treated as one message. The framing method chosen for our messages, utilizes a delimiter (we use the hex value 0 × 0 A, i.e., the linefeed character) to indicate the boundaries between messages, by appending this delimiter to the end of every message. Thus, there is only one byte of overhead per message, and communications errors are generally recoverable for multiple message streams, as the next correctly received delimiter will be correctly interpreted.

Recordstore Data Format
Our sensor device relies on an inexpensive, and low-power microcontroller with limited computational resources. Since we must store sampled measurements to be later reported to the server, limited memory space can restrict the amount of power we can save by limiting the number of measurements that can be stored. For example, the ATmega1284 microcontroller that we use contains 16,384 bytes of RAM, 2416 of which are used by our program. The average size of a message containing a measurement is 29 bytes, therefore, without compression, the maximum number of messages stored is 481. If a message is generated every 10 s, this corresponds to about 80 min of data stored. Thus, we developed the recordstore data format that the device uses to store messages to be later transmitted to the server. This provides simple and efficient compression, taking advantage of the fact that sensor data messages are very often the same length and have many repeated bytes, especially at high enough sample rates where environmental conditions do not change much between samples. Furthermore, we point out that the acquisition rate can be lowered for applications with slow dynamics such as thermal processes, which can reduce the storage problems while maintaining the monitoring performance.
In addition to the messages being stored in the devices' RAM in this manner, messages are also transmitted to the server in this format (in fact, the contents of the memory are simply "dumped" onto the communications channel). This therefore reduces the communication load. An additional advantage of the recordstore format is that it is stream-based, meaning that previously inserted bytes do not need to be changed (although they are referenced). The primary disadvantage of this format is that it will perform very poorly for rapidly changing data, such as measurements taken with very long sample intervals. In these situations, more overhead bytes may be added than the number that is saved by compression. Another minor disadvantage is that the compression technique limits the size of each message to 128 bytes; however, we currently have no need to send messages this long. In an experiment where 500 measurements were taken, once every 2 s, the recordstore method achieved a compression ratio of 1.5:1, or a reduction in memory requirements of 30%. Primarily, this serves to allow more samples to be stored in the device's memory prior to a report being sent. If latency is not a concern, this compression can significantly increase battery life due to fewer reports needing to be sent to send the same amount of data. Compression of time series data is an interesting and useful direction of study, for which the algorithm described is only an initial result. Future work will attempt to compress the data further since it is so important to the battery performance of the sensor. Figure 5 is an illustration of the data structure of the recordstore format. The memory block contains a list of records, each of which encapsulates one message. There are two types of records: template records and delta records, represented in Figure 5 by the solid and hatched blocks, respectively. Additionally, to improve efficiency, a list of template pointers keeps track of the template records for quick referencing.
The exact format of the messages and the techniques used for encoding and decoding the messages are detailed in [17]. Figure 5. Diagram of the recordstore data structure in a typical scenario. There are two sets of records in this scenario, designated by the yellow and blu·e blocks. The solid yellow and blue blocks are the templates for that type of record and the hatched blocks are delta records that refer to the respective templates.

Hardware Design
The objective of the hardware design for BiB is to design a permanent, reliable and easily deployable sensing infrastructure that can operate for many years inside a smart building. Since the design is from the ground-up, we have a great amount of flexibility in choosing state-of-the-art components available. The hardware design and the block-level diagram of the BiB sensor are demonstrated in Figures 6 and 7, respectively.

Microcontroller
The logical center of the hardware design is Atmel's ATmega1284 microcontroller. This particular choice has a high amount of program memory (128 KB) and RAM (16 KB), which allows us to add in many code features without running out of space. More importantly, the microcontroller has the peripheral features required (I2C, SPI, and two UART ports), and the capability of low-power sleep while operating a 32.768 KHz crystal. Even though there are many microcontroller families (e.g., Texas Instruments' MSP430, Microchip's PIC) that satisfy our requirements, we chose the ATmega family due to its reliance on an open-source and free toolchain (GNU GCC) and extensive community support through the Arduino community (e.g., the community provides driver code for many sensors).

Radio Module
The radio module is another critical component for a wireless sensor. The function of it is to communicate with an endless variety of protocol and protocol combinations, considering the layered model of communications. We included a 20-pin socket, popularized by the ubiquitous XBee module, which is the connector footprint that is used by many of Digi's OEM XBee modules initially, because we did not seek to tie our design to a specific wireless module. Numbers of companies produce the XBee modules that adhere to the same connector footprint and signal locations due to its popularity. This allows us to evaluate these alternative offerings without a hardware redesign of our board. Eventually, as shown in Figure 7, we chose Roving Networks' RN-XV module as it proved to provide the most reliable communications in real deployments, owing to the retry-enforced reliability of the TCP protocol. Although the power consumption of this WiFi transceiver is up to 10 times greater than Bluetooth or IEEE 802.15.4 products, the high data rate (over 200 times faster) allows us to transmit many measurements in one "burst", thus limiting the time that the radio must be turned on in tandem with the more reliable transmission over a long range to reduce transmission failures; this is able to increase power efficiency.

Power Supply
The BiB sensor is powered via a 3.7 V Lithium-Thionyl Chloride battery with a nominal battery life of 9 Ah in the standard configuration. This particular chemistry is intended for powering long-lifetime devices, having a low self-discharge of less than 1% per year. Nevertheless, the capacity of the battery is reduced in some situations. One scenario is when pulling more than 2 mA of continuous current or more than 400 mA of pulsed current. The capacity of the battery is also reduced at lower current levels, such that, at a 100 µA current draw (roughly the average draw of the sensor), the capacity is roughly 8 Ah. A 100 µF capacitor is used in our design to lightly buffer the current draw during the times that the radio is active in order to overcome the problems associated with current. Since the designed system voltage of BiB is 3.3 V, a linear regulator is leveraged to drop the 3.7 V battery voltage to the required voltage level. The system can also be supplied with another power source of up to 6 V and as low as 3.5 V. Because it is a recognized issue in building monitoring that setting up the sensor network is not easy, we chose the battery as the power source instead of using power cords or RF transmission because it makes the sensors portable and convenient to deploy at different locations, where the alternative powering sources are either not available or cumbersome to set up.

Sensing Capability
In this section, we introduce the environmental variables that BiB is capable of measuring. Table 1 below is a summary of the modules and performance parameters.

Temperature and Humidity
Measuring temperature and humidity from the local environment is accomplished by Measurement Specialties' HTU21D instrument. This instrument is attached to the shared I2C bus and can be queried to provide 12-bit and 14-bit digital readings of relative humidity and temperature, respectively. The stated accuracy of the humidity sensor is ±2%RH typical over the 20%RH to 80%RH range, and up to ±3%RH outside of this range. The maximum error tolerance is stated to be ±5%RH over the whole range. Although the instrument is calibrated at the factory, the relative humidity reading must be temperature-compensated to achieve the stated accuracy. The coefficients and formula needed for this correction are specified by the datasheet. The stated accuracy of the temperature sensor is typically ±0.3 • C and maximally ±0.4 • C over the range of roughly 5 • C to 60 • C, which covers the expected range of temperatures encountered indoors well.

Ambient Light
We employed AMS' TSL2560 instrument to measure the ambient visible light for BiB sensor. This design of the integrated circuit (IC) incorporates two light-sensing photodiodes: one measures visible and IR light from 300 nm to 1100 nm, and the other measures IR light from 500 nm to 1100 nm. Therefore, the reading from the second (IR only) photodiode can be used to compensate for the light energy that the first (visible and IR) photodiode measures but is not visible to the human eye. An additional feature of the instrument is the ability to change the integration time of the on-board analog-to-digital converter (ADC), which can be changed depending on light conditions (e.g., a long integration time for dark environments). However, in our implementation, we have fixed the integration time to 101 ms. This instrument is attached to the shared I2C bus allowing the microcontroller to configure the instrument to read the 16-bit values the two photodiode measurements, which are used by the microcontroller to calculate a lux reading. We also used the interrupt feature of the instrument, which detects when the light level crosses above or below a preconfigured threshold. When enabled, this allows our sensor to timestamp events such as when the sensor is put inside a drawer or the lights are turned on and off.

Orientation
The orientation of the device is measured by the LIS3DH Accelerometer by ST Microelectronics. It can be also utilized to measure high-acceleration "bumps", such as footsteps, which can be fused with other sensing modalities (e.g., WiFi, Bluetooth) to estimate occupant locations and provide context-aware services [18,19]. Detecting orientation and bumps provides information in a mobile environment (e.g., we can place a BiB on a mobile robot to enable "automated mobile sensing" [20]). The orientation data provided by the three-axis accelerometer can facilitate building status and occupant monitoring. For instance, if one BiB is attached to the door, the accelerometer readings could reveal the events of opening/closing the door, which is a good indicator of indoor human traffic. If one BiB is attached to the chair, the accelerometer measurements could reveal whether the occupant is sitting on the chair for activity recognition. If another BiB is attached to a ceiling fan, the accelerometer readings could be used to estimate the speed of the fan for fine-grained status surveillance. With this feedback information, we can easily detect whether the fan has malfunctioned or enable occupancy-adaptive fan control.
In these situations, the accuracy of the instrument is not of large concern. For orientation purposes, the typical magnitude of acceleration we are measuring is 1 g, so the stated offset error of 40 mg represents about a 4% error. We use the interrupt capabilities of the device to inform the processor when the orientation has changed since the x, y, or z measurement axis is aligned with the gravity vector. The three 16-bit values of acceleration are read from the device over the shared I2C bus.

Motion Detection
We measure motion with Panasonic's AMN41121 passive infrared (PIR) motion detector module. This module utilizes a pyroelectric element to monitor small changes in infrared black-body radiation emitted by humans (7-14 µ).
The special property of this module is that there is a specialized lens that forms a pattern of discrete detection zones corresponding to one of four sensing regions of the pyroelectric element. Further circuitry within the device monitors changes the infrared measured by the four regions to determine whether a detection event has occurred. The sensor will detect when an infrared-emitting body eventually when an occupant moves across the detection zones, but remain insensitive to overall temperature increases or decreases within the field-of-view. The experimental results have shown that the sensor is also insensitive to an unmoving human. The field-of-view of the sensor is stated to be 100 • along one axis and 82 • along the other, and the detection range is at least 5 m from the sensor. Within this cone, there are 64 discrete detection zones distributed somewhat uniformly. A drawback of the module is that it needs at least 7 s for the circuit and sensor to stabilize before the detection is reliable. Therefore, we realistically cannot duty-cycle the sensor to save power; however, since the static power consumption is only 46 µA, we can leave the sensor powered and still achieve long battery lifetimes.
The module interfaces to the microcontroller via a single output that connects the attached signal to Vdd (HIGH) when a detection occurs. An external pull-down resistor pulls the signal to ground (LOW) otherwise. Although the datasheet does not specify the timing of the signal during detection, we have found that the signal will stay HIGH as long as there is activity but can sometimes intermittently go LOW, even while humans are moving in front of the sensor. Therefore, we require some intelligent interpretation of the signal, rather than simple assuming that a HIGH signal means occupants are present and a LOW signal means humans are not present.
There are two calculated measurements to report: one is the occupancy percentage, which is the percentage of time (with a resolution of 1/256 s) that the signal was HIGH over the last sample interval. The second is the occupancy state changed event, which sends a value of 1 if the signal goes HIGH after being LOW for 10 s, or sends a value of 0 if the signal is LOW for 10 s after previously sending a 1. These two measurements are sufficient to determine whether the space in front of the sensor is occupied by one or more occupants.

Extension Capability
Besides the on-board sensors, the BiB sensor also has the expansion port to allow virtually limitless expansion possibility to interface other sensors. The expansion port is a 10-pin male IDC connector with standard 0" spacing. The port exports an SPI Master interface, including clock (SCK), Master-Out-Slave-In (MOSI), Master-In-Slave-Out (MISO), and a single slave Chip Select (CS) line. These four signals can also be used as General-Purpose Input Output (GPIO) pins, including the ability to timestamp changes in voltage. The shared I2C bus is also available on the expansion port, composed of the Serial CLock (SCL) and Serial DAta (SDA) signals. It should be noted that all of these pins operate using 3.3 V digital logic levels and are not intended to communicate with 5 V logic levels. The expansion port includes four power-supply pins: two GND pins, VCC, which is the system voltage of 3.3 V, and VBATT, which is either 3.7 V from the lithium primary battery, or can be used as a 3.5 V to 6 V supply input when the battery is not being used.
There are various external devices that have interfaced to the BiB sensor board to allow other types of measurements. One of the potential integrated external devices is CO 2 sensor. Sensing CO 2 has wide usage in intelligent building research, particularly in occupancy estimation [4]. We have successfully interfaced the K-30 CO 2 sensor from CO 2 Meter to the expansion port of the BiB sensor board. The K-30 sensor achieves an accuracy of ±30 ppm ±1% using a self-calibration procedure called Automatic Baseline Correction (ABC), which adjusts the readings such that the lowest value in the last 7.5 days is equal to 400 ppm. An external power source is required since the K-30 sensor requires a power input of 4.5 V to 9 V at an average current of 40 mA and maximum current of 300 mA.
We connect the VBATT input of the BiB sensor to the power supply of the K-30 device, so that they share the same power source.

Firmware Design
The firmware design of BiB system is mainly completed on the ATmega microcontroller. There is no underlying operating system for this design. The ATmega microcontroller was programmed in C code and debugged using the on-board JTAG connector. The code is organized logically as follows: • Device drivers-code that knows how to configure and extract data from the instruments.

•
Peripheral drivers-code that knows how to configure and use the ATmega hardware peripherals that are shared between multiple modules. Drivers for hardware peripherals that entirely used by one code module are usually included within that module.

•
Radio drivers-code that knows how to configure and use the attached radio transceiver. The operation of the sensor can be summarised as a finite state machine with four states. As shown in Figure 8, they are:

•
The machine begins in the SLEEP state, which represents the lowest-power state.

•
The machine may be interrupted (e.g., by the PIR sensor) and transition to the CHECK ASYNCH state that interprets the interrupt and possibly creates a Sensor Data Report.

•
The machine may also transition to the SAMPLE state if it is time to read the next periodic sample and create a Sensor Data Report. A transition to this state triggers the sampling schedule to execute. • Finally, the machine transitions to the REPORT state if it is time to transmit the stored samples to the server over the radio. The processor must activate the peripheral instruments when the machine transitions to the SAMPLE state, instruct them to make a conversion, wait for the conversion to complete, and then retrieve the conversion result. The processor can be simultaneously communicating with another instrument to make the system more efficient when it is waiting for a conversion to complete for one instrument. In addition, a simple real-time scheduler is provided for the device drivers to use to schedule their operation to make this process straightforward. This sampling scheduler is triggered when the SAMPLE state is entered. The scheduler allows drivers to specify the earliest time that a task should be executed.
The sampling schedule for instruments on the BiB sensor is demonstrated in Table 2. The first column gives the time offset from when the sample is triggered. As presented, the light and the temperature/humidity instruments require a conversion time that is enforced by the scheduler. When more than one task is specified to execute at the same time, such as at the 1 ms time offset, the scheduler executes them in the order that they were placed into the queue. As shown in the last row of Table 1, there is a special value of time offset, LAST, which instructs the scheduler to execute the task after all other tasks. In order to save power, the scheduler turns off the CPU when no tasks need to be run.

Application and Evaluation
In this section, we perform evaluation of the power efficiency of the BiB sensor, which is an essential aspect for building monitoring. Several potential applications, including occupancy estimation and activity recognition, which rely on the BiB for experiments, are described, as a demonstration of the portability and accessibility of the BiB platform.

Power Efficiency
The power efficiency (battery lifetime) is one of the critical aspects when we design the BiB sensor to make it to achieve a multi-year battery lifetime to reduce the maintenance cost of the network. In order to bring down the average current consumption to a target of less than 200 µA, several strategies have been employed.
For instance, we select the components with low current requirements only. This helps us reduce the amount of energy consumed, as well as reduce the peak load demanded to be supplied by the linear regulator and battery. Linear regulators with higher peak current capability also typically have a higher leakage current. The high peak current draws can damage or reduce the effective capacity of the battery. Since the most vital component of the BiB sensor is the radio transceiver, we did the selection of it cautiously. Eventually, we selected the Microchip's RN-XV module instead of others such as the XBee-PRO and XBee Series 6 (WiFi) because of their high (over 300 mA) peak consumption. The CO 2 extension module can potentially increase power consumption. To address this issue, we can either lower the sampling rate of the CO 2 sensor, or use high energy efficiency CO 2 sensors. However, because most CO 2 sensors require a warming time of several minutes, reducing the monitoring frequency may not substantially reduce power consumption due to this compounding effect.
Furthermore, we create power consumption worksheet to determine the feasibility of having a multi-year battery life. We list the power requirements for each device during their sleep and active modes, and the typical amount of time required to be active to perform their functions. After that, we simulate and plot (as shown in Figure 9) the battery lifetime of the BiB sensor powered by the 3.7 V Lithium-Thionyl Chloride battery, over varying values of sample intervals and report intervals. The current consumption from the light sensor, humidity and temperature sensor, accelerometer, PIR sensor, microcontroller, and radio is simulated. In addition, we also simulate the reduction of battery capacity at a low average current draw. Based on our analysis and evaluation, the BiB sensor can achieve a battery lifetime of over five years by using a 10 s sample interval and 60 s reporting interval ( [21], Chap. 4). In this configuration, the average current consumption is 168 µA, and the effective battery capacity at this current is 8.03 Ah. The amount of current being used for communication is 56 µA, 57 µA for sensing, and 47 µA for processing. Another 8 µA is used for inactive devices while they are in their respective sleep modes. Furthermore, we note that with the extension of additional modules such as a CO 2 sensor, the power consumption is expected to increase.

Occupancy Estimation
Various methods have been employed for occupancy estimation, such as passive infrared (PIR) sensors, ultrasound sensors, and magnetic switches. These types of sensors provide accurate detection of occupants; however, the information they provide is limited. For instance, these light-based and ultrasound-based sensors usually have a small detection volume and cannot distinguish the number of occupants or the amount of activity that is occurring [22].
To explore techniques that do not have these limitations, the occupancy level of indoor spaces is directly estimated by measuring the CO 2 concentration with BiB sensors [16]. The dynamics of the CO 2 concentration in the room is modeled using a convection PDE with a source term that is the output of a first-order ordinary differential equation (ODE) system driven by an unknown input that models the human's emission rate of CO 2 . The source term represents the effect of the humans on the CO 2 concentration in the room. In the experiments, a delay is observed in the response of the CO 2 concentration in the room to changes in the human's input. For this reason, the source term is a filtered version of the unknown input rather than the actual input. It is assumed that the unmeasured input from the humans has the form of a piecewise constant signal. This formulation is based on our experimental observation that humans contribute to the rate of change of the CO 2 concentration of the room with a filtered version of step-like changes in the rate of CO 2 . Figure 10 shows a typical trace of CO 2 concentration when the occupancy changes. As can be seen, the extension capability of BiB sensors to measure CO 2 concentration is directly applied in this study. At the conclusion, a PDE-ODE model is developed that describes the dynamics of the CO 2 concentration in a conference room. An observer is designed and validated for the estimation of the unknown CO 2 input that is generated by occupants, which acts as an intuitive proxy for the number of occupants breathing in the local air space.

Activity Recognition
Building intelligence encompasses its ability to sense and understand the activities of occupants to interact with them and achieve goals like comfort and energy efficiency. Individuals perform various activities inside the building. This information, when made available to the building automation and control system, can be very useful. For example, the predicted mean vote (PMV) model adopted by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) as the primary standard for thermal comfort takes occupant metabolic rate as one of the most important factors, but it has been widely regarded as the most difficult parameter to measure [23].
The BiB sensor was adapted into a watch to enable fast prototyping of wearable sensor research [24]. The goal of using BiB was not to be smaller than the current offerings, but rather to be small enough to enable these studies. It was shown in [24] that indoor occupancy activity can be recognized and classified by leveraging the environmental measurements, including temperature, humidity, and lighting level. Features including temperature gradients and standard deviation, humidity standard deviation, and lighting levels are proposed for activity and location recognition. The features are statistically shown to have good separability and are also information-rich. Fusing environmental sensing together with acceleration is shown to achieve classification accuracy as high as 99.13%. For building applications, this study motivates a sensor fusion paradigm for learning individualized activity, location, and environmental preferences for energy management and user comfort [25].

BiB Deployment to the Public Space
To demonstrate the BiB solution in use, we endeavoured to deploy briefcases into the Singapore environment (see Figure 11). A total of 50 briefcases were manufactured and assembled. Sites within the Singapore environment were chosen by invitations and via volunteers. Additionally, there were sites from collaborating research partners as well like Bosch PLC Singapore and Nanyang Technological University (NTU). The sites in general vary from office spaces, a public school, private residential homes and lastly the Singapore-Berkeley Building Efficiency and Sustainability in the Tropics (SinBerBEST) laboratory and collaborating university research laboratories within Singapore's research community. The physical deployment was done either by the owners of the volunteer sites or by SinBerBEST's own technical team supporting the project. In the case of the site owner deployment, it demonstrates the ease at which a briefcase can be deployed. The following map figure depicts geographically the deployed BiB briefcases within Singapore. These deployments span timewise from January of 2015 to the present day.
Other than for data mining for research, some site owners were motivated to deploy and get environmental data of their premises as an aid tool to gauging, for example, the amount of light a specific space admits. With this information, one could determine if the space would need additional lighting fixtures to augment shortcoming or even if too much added artificial lighting is being provided and can thus be cut back on thereby also saving the cost of energy to power the added artificial lighting. Another example would be temperature variations where the sensor can help profile a space to evaluate the need for air conditioning. An example of such a case is given further below with the Punggol Primary Schools where six briefcases are deployed.

Data Services and Network Connectivity
We purchased and employed the use of a local Singaporean telecoms service provider for GPRS radio data services and in particular a Machine to Machine (M2M) type service package. The package typically allows for a collective bundled amount of data usage per month from the collective number of purchased SIM cards consumed by each briefcase (via the attached USB dongle MODEM attached to the WiFi router). The service package offered the administrators of the project the opportunity to be able to monitor and evaluate the amount of data generated per day for a chosen site. As a rule of thumb, a 32 Mbyte daily limit alarm was applied to keep track of daily data report activity (for the typical office space, a briefcase was deployed in), and it was found that this limit was more than sufficient. On occasion, this limit is broken on the premise that there were instances when the M2M data network experienced an outage, and, upon reconnection, the reporting service within the router attempted to push the captured data back to the data server hosted over at SinBerBEST offices.
The amount of data generated based on the records provided by the M2M data service package management console gave good approximations of collective sensor activity by site. Take for instance where a site had much movement and occupancy change rates. The amount of data harvested from the occupancy aspect resulted in more frequent data transmission that ideally also results in more sensor report activity (though a fixed window of 120 s is applied for the reporting windows). For some collaborators, it was requested that the frequency of reporting was increased and this obviously translated to a shorter battery life span for the sensor.
The volume of data harvested varied upon the site, deployment environment changes (abrupt or gradual) and occupant activity. The placement of a sensor is also a critical consideration.

Key Challenges
Some of the key challenges faced were mostly related to operational issues like knowing when a battery from a sensor node has expired because, in many situations, it is costly to perform on-site measurements. This can ideally be confirmed by viewing the data feed stream from the data server; however, this is not easily done as there are many sensors deployed. Other challenges include cell network data connectivity losses that result in queued data within the routers storage flash drive. The challenges, however, can be addressed by incorporating software features to be able to update specific Key Performance Indicator (KPI) variables for the purpose of monitoring and managing the large number of deployed sensor nodes. This can be implemented within the router itself and the health check routines reporting in the health KPI variables as part of the data feed.

Visualizing and Sharing Data
Apart from the time series data capture, specific visuals were also created to the benefit of the participant and volunteers. In the case of the public primary school participant (Punggol Primary School, whose location is shown in Figure 11), we deployed six briefcases where four were for non-air conditioned individual classrooms (shown in Figures 12 and 13), one for the school's non-air conditioned assembly hall cum gymnasium and the final case to the school's air conditioned library (shown in Figure 14). Our system gives the volunteers/participants the opportunity to view the data over a live data feed channel with a non-cryptic and non-technical sense. With the visual as an aid, the teachers were able to share with their students an understanding of the classroom and library environments, which also served as a teaching aid in basic energy savings involving air conditioning and the use of lights based on ambient lighting levels measured by the sensor nodes. On a larger scale, the recorded temperature data will be used to determine the need for air conditioned versus non air conditioned classrooms for atypical Singapore schools. The captured data presents the opportunity to study the indoor air quality in classrooms to ensure student performance and health [26].

Related Work
Prior to designing a custom hardware solution, we first evaluated alternative commercial solutions, as shown in Table 3. Some platforms, such as the Digi XBee Sensors [27], are commercially packaged, produced and sold through major distributors, which makes it extremely quick and convenient to build a platform upon. However, none fulfilled all our requirements of variables sensed, battery life, or cost. Moreover, proprietary solutions prevent us from extending the sensors to measure more variables, installing experimental networking protocols, and are also vulnerable to becoming unsupported by the company.
Finally, there are proof-of-concept and short-run products such as the Powercast WSN-1101 [28] (and derivatives), which featured remarkable improvement in battery life and package size. Sensor nodes like these are usually developed by companies to demonstrate an underlying technology innovation (in this case, wireless charging, low-power micro-controller, and energy storage improvements). In many cases, the true product is an OEM module that is sold to other companies to integrate into a commercially packaged product.
The design of BiB differs from them by making the system trivially easy to deploy, enabling easy access to a variety of environmental parameters through effective visualization and data aggregation, which opens up many possibilities for large scale data mining for building managers and researchers alike.

Conclusions
A thorough understanding of indoor air quality and occupancy distribution is necessary to achieve the potential of improved building energy efficiency and reduced environmental impact, without compromising occupant comfort, safety, security and productivity. We should consider the grid, the building and its occupants, as an ecosystem in order to achieve the cooperative optimization of the interactions between them. The objective of the Building in the Briefcase system is to provide a portable sensor platform for indoor environment monitoring and optimal building energy management that is simple to deploy in any building environment.
In this paper, innovative design and implementation of the BiB are demonstrated. The BiB sensor we have developed is small-size, low-cost, battery-powered and light enough to be unobtrusively installed in any type of indoor environment. It is capable of collecting a rich set of environmental parameters, and is expandable to measure others, such as CO 2 . The hardware design of the sensor, including the microcontroller, radio module, power supply, sensing capability, and extension capability were selected to maximize the portability of the BiB system. The environmental data collected by BiB sensors are wirelessly sent to the BiB router via TCP/IP protocol and Wi-Fi technology. Then, the data are securely forwarded to the central database through the 3G network. As we described in the paper, the communication protocol, the database server, the data visualization, the BiB router and the implementation of 3G modem communications contribute to the full-scale accessibility of the BiB system. These unique portability and accessibility features of BiB make it possible to be deployed in varied building environments. They also allow for scalability. The implementation and impact of the BiB system will be enormous and profound in the field of academic research, as well as in the practical fields of building management.
Our vision of BiB is to transform the practice of building environment and energy management through large-scale deployment. We have demonstrated deployment of a large quantity of BiB in buildings in Singapore to monitor the indoor air quality and environment. We will also keep adding services on top of the platform to improve its functionality and user experience.