Use Cases: detailed narrative examples

Using Environmental Data

(Words in italic parentheses relate to the information model diagram.)

Supports the Use Cases: What do you mean all the rooms are booked?, Intelligent Spaces for learning, There’s no room!, Building Analytics and If the walls could talk.

An HE institution installs Safehouse environmental sensors (Activity Source) in its buildings. Via these sensors the institution can collect real-time data about humidity, temperature and sound levels (Activity Measures). It already has the estate mapped using a BIM system (Application providing Context Source), so that information about locations and some learning and teaching capabilities are captured (Activity Context). The data here includes identification and location of rooms, geolocation of specific points such as entrances, the shapes of buildings and some of characteristics of rooms (Activity Context). Real-time occupancy of rooms is also measured (Activity Measure).

The institution has integrated occupancy information with their timetable system (Application providing Context Source), so that staff can manage timetable loading and identify available or underutilised space (Algorithm). The environmental sensor data is linked to geolocations, but not yet fully integrated. Data feeding into a Data Hub will enable this sensor data to be linked to individual rooms in buildings over time (Algorithm). Extending integration to timetabling means that the sensor data from individual rooms can be linked to specific teaching and learning events that form parts of modules (Analytics). In addition, student participation in these events can be obtained and reviewed from activity data collected from attendance monitoring systems (Analytics and Applications).

The institution develops a tool to show the utilisation and expected utilisation of rooms for a range of modules that have regular lectures and other easily modelled events. These questions can be reviewed through 1 integrated tool and are in addition to questions about student attendance that could be picked up directly from attendance monitoring. The information enables staff to:

• Review the past attendance of students on the module at specific lectures, compared with expected attendance, and project into the future (high or low?)
• Compare the times of room bookings with occupancy, both occupied/empty and approximations of student numbers (are there rooms that are over- or under-utilised?)
• Spot whether cancelled lectures have led to others picking up the empty room (can we handle cancellations better?)

Data behind the dashboard

Data to create the example of a dashboard above comes from several sources. The environmental data sent from sensors is defined by the measurement specification. For example occupancy might be reported like this:

"measurement_event": {
    "context": {
        "id": "kccBCAICAQYR/zMBF2QOEAABARoB1gCfAQAJCUQ2QjI3ODiP",
        "location": {
            "room_id": "AS34"
        },
        "timestamp": "2019-06-10T12:15Z"
    },
    "measurement": {
        "id": 129,
        "type": “occupied”,
        "value": “false”
    },
    "sensor": {
		"id": "15"
	}
    }

Rooms are identified and mapped via a BIM system and are mapped to identifiers in the timetabling system. The sensor in the example (cf. Lone Rooftop) only has "occupied = true/false"; in Lone Rooftop this would be “Isempty: true”. It would be possible to use more Lone Rooftop data to look at numbers, so that utilisation could be measured.

An Intelligent Campus booking_event record might look like this (non-relevant data omitted):

BOOKING_EVENT__ID	NAME	ROOM_ID	MOD_INSTANCE_ID	START_TIME	END_TIME
1234	Lecture: Introduction to computing	AS34	mi_01	2019-04-02T10:00	2019-04-02T13:00

On the UDD, the module instance data is in the module_instance record. This includes both MOD_INSTANCE_ID and MOD_PERIOD. The latter refers to data identifying the start and end date of Semester 1. In addition, the UDD’s EVENT entity has EVENT_ID that matches directly with BOOKING_EVENT_ID.

In this case, several potential links between the data sets can be identified:

• ROOM_ID is on the measurement_event, the Intelligent Campus booking_event and the UDD event.
• Intelligent Campus booking has the BOOKING_EVENT_ID that matches with the UDD EVENT_ID.
• MOD_INSTANCE_ID is on the Intelligent Campus booking_event and on the UDD module_instance. It would also be on any relevant xAPI activity statement too.
• Intelligent Campus BOOKING_PERIOD should match to an entry (PERIOD_CODE or PERIOD_NAME?) in the UDD PERIOD table.
• Using the UDD, we can see the number of students on the module and extrapolate those that should be at the lecture

In theory then, a dashboard could show:

• Module
• Lectures on the module
• Rooms where the lectures will be / are being / have been held
• Dates, times and frequencies of the lectures
• Number of students expected to attend and actual attendance via xAPI attendance data
• Whether the lecture went ahead (from occupancy)
• Any mismatch between the booked time period and actual occupancy. For illustration, this example shows that, although the room was booked from 10:00 till 13:00, it was empty at 12:15, suggesting that the room is underutilised.
• With Lone Rooftop (or similar) utilisation figures, it might be possible to show that the numbers suggest that Room AS34 is too large or not large enough for this group.