After a briefing about the breadth of the problem space and a history about EDP from our Logica representatives on campus, we dove into the literature about energy management, control, and visualization. We consulted with HCI department faculty from Pittsburgh and Funchal, collecting valuable resources. The team divided, read, and summarized scientific papers and books on topics ranging from cognitive load theory to current trends of SCADA and information visualization.
We read about the challenges and expectations of stakeholders along the energy delivery chain from producers to consumers. We learned about the common software tools EDP operators rely on to keep track of activity on the grid and make changes when power needs to be redistributed. Between its two central control stations in the northern city of Porto and the south’s Lisbon, EDP monitors electricity distribution at high, medium, and low voltages. Literature review findings were discussed, consolidated, and logged as references for protocol formation. We knew the important elements in the energy control domain and set about discerning how to learn about our users. Contextual inquiry was selected as the primary method of user research since the responsibilities and contingencies of an EDP operator are directly linked to their environment and the changing status of the energy grid.
An interview protocol was drawn up to inquire about basic systems' functionality and about operators' overall satisfaction with their working environment. Questions were refined and rehearsed to ensure objective, unbiased conversations with EDP staff. When preparation was completed, we visited EDP's distribution control centers in Lisbon and Porto where we visited two operators in each of three voltage levels (high, medium, and low). Additionally we talked with in-house veterans of the energy management domain to confirm emergent themes and make sense of industry-specific practices. Our team split into pairs and we talked one-on-one with operators and asked them our questions about the systems they use, what was good, what was challenging, and how they'd like to work in the future.
After three rounds of sketching different looks for the core utilities of this interface, we put a paper prototype in front of some control room operators. These users stepped through use cases by pointing and talking about parts of the paper prototype. Interactions were implied with the help of a team member by changing the grid views and visible information based on the operators' "clicks". Our two primary interests in this test were to evaluate the suggested interactions and information visualizations. Users did not grasp the illustrated grid views easily, however the flow from one grid view to another seemed natural; we received a positive outlook and expectation for the interface’s potential.
Users were unanimous that they wanted to see it running with actual data to confidently assess its usefulness. For actual interactions, operators expected more data moving from the default view to secondary views. There seemed to be a disconnect between what people selected and what they saw on subsequent screens. Despite challenges, users expected that the added functionality of the prototype complemented the existing SCADA management system and they could see the tool implemented in the future. Looking to the next version, we focused on improving the interaction flow and adding real world data to test with users.
After processing feedback from first-round user tests, we outlined the technology necessary to make the prototype interactive on a real computer. Core feature of the interface were well-received but users wanted to see a working version on their monitors. To reduce clusters' ambiguity, a programmatic rule was applied to give proportionate spacing to different and related clusters. Clusters’ color was also changed from just one for all to different hues indicating the number of affected customers.
At this stage the primary cluster view includes four levels of information: importance of clusters indicated by the size of circles, clusters' tagged location relative to their geographic origins, the number of affected customers indicated by color, and a record of previous alarms in a timeline at the bottom of the interface. For the timeline, users can go back in time to examine clusters’ behavior and grid activity in previous days, weeks, or years.
In the secondary grid view we have an alarm count indicator to each node and use power lines' color between nodes to indicate whether connected nodes are affected or not. The grid view has 4 layers of information: affected nodes and how they are linked as displayed by icons and lines between them, number of alarms per node displayed via a red circle counter next to each node, affected lines indicated with red highlights, and real-time metrics tagged to each line and node. Users can also click on each node or line to get more details. In the geo-view we also include more weather visibility and a capability to filter map attributes. Layers of information in the geo-view include: Geographically accurate view of affected areas, outages are indicated by red highlights, alarms' origin point is shown by a blue circle, weather information (temperature, rain, and wind) is displayed as colors in a heat map, and ground teams are shown as icons at associated nodes. Each element is clickable, resulting in a pop-up that details every marker.
After a collaborative test and discussion with representatives from our client, Logica, and our users from EDP, we got positive input confirming the design choices of InContext. The primary input from EDP was an imperative to display affected customers in every view of the energy grid. Favoring affected customers over alarms is a more meaningful, useful metric to dispatch operators. This perspective of the energy grid also distinguishes the application from traditional SCADA systems by positioning InContext as a business intelligence tool. EDP also specified a need to predict adverse future events based on historical data, and a need to reveal more real world conditions in the secondary grid view.
Logica asked us to address a specific problem: some low-level alarms go unnoticed for too long and if unchecked can escalate to full blackouts. Metrics for calculating the importance of a cluster based on time and size should factor into alarms’ priority. EDP recognizes correlating multiple measures related to alarms is novel, e.g. grid events, weather, and affected customers, and this feature has serious potential for changing grid management. To accommodate needs and requests from Logica and EDP, we added an event prediction feature and adjusted the algorithm by which alarms’ importance are displayed in clusters.