C3Fire

Changing teamwork tasks in international mission collaboration - Tasks and workload

From C3LearningLabs


Year 2017
Project Name SweCan-Teams Pilot 1
Project Pilot study to test team role changes in international mission oriented tasks.
Acronym SweCanTeam1
Organisation Linköping University, Laval University
Country Sweden, Canada
Contact Person Rego.Granlund@C3learninglabs.com
Project Members Rego Granlund, Sebastien Tremblay, Isabelle Turcotte, Björn Johansson, Peter Bergström, Oscar Bjurling and Jacob Weilandt

Experiment Design: Rego Granlund, Oscar Bjurling and Jacob Weilandt.
Experiment Leaders: Jacob Weilandt and Oscar Bjurling
Thesis advisors: Björn Johansson and Peter Bergström


Project

This project is performed in collaboration between research groups in Sweden and Canada. In Swenden the works is performed by Linköping university. In Canada the work is performed by Laval university. The long time goal is to study collaboration in international teams when the team role structure changes during mission or between missions.

In this specific experiment series we studied:
1) how the workload in a team was related to the team members individual workload.
2) the possibility to detect if any individual team role had a greater impact on team performance than the other roles.


Experiment modules

Tasks
Forest Fire Yes
Search and Rescue Yes

Resources
Fire Fighters Yes
Fuel Logistic No
Water Logistic Yes
FireBreak No
UAV / Drone Yes
People Transportation Yes

Communication Tools
Mail Yes
Chat No
Diary No
Chared Map No
Map Symbols No
Voice No

Decision Suport
Prediction No

Method

Scenario

The first two scenarios were training scenarios designed to give the participants time to familiarize themselves with their respective roles. The first training scenario was a simple scenario with only one active fire and a slow ignite time. Its purpose was to allow the participants to get a handle on the basics of how each of their role functioned, how the map functioned, how movement functioned and how to communicate. The second training scenario was designed to be more hectic and utilized a slow ignite time but starts with three fires simultaneously. This scenario was meant to introduce the participants to the task of fighting several fires at once and further show the participants the importance of having a functioning supply chain and communication as well as division of labour. 17 The three experiment scenarios were all similar in function and game length, each scenario lasting for 15 minutes. The scenarios only differed in ignite time and map rotation. Each scenario was structured to have three fires ignite during the play time, with each fire starting at a different time. One fire started immediately as the scenario was started, the second fire started four minutes after that and the third fire starting another three minutes after that. As the map was rotated in each scenario the fires spawned at different coordinates for each scenario.


The independent variable used in this study was the ignite time configuration in C3Fire. The ignite time setting dictates how long it takes for any cell adjacent to a fire cell to burst into flame. It is one of the primary settings that define how quickly fire spreads, and thus the level of difficulty. The ignite times used in this study were 60, 80, and 100 time units, where 60 is the shortest ignite time which would make this the most difficult setting since the fire would spread more quickly. These ignite times were configured in three separate scenarios; D3-100, D1-80, and D2-60, representing the 100, 80, and 60 ignite time settings, respectively. The simulated world was partially hidden from view on the interface maps. Static objects like trees, houses, and pumps were always visible to participants, but certain objects—like civilians, fires, or even the units of other participants—were invisible on the map until they were within the line of sight of any unit. These objects would then be visible to the participant controlling the unit that spotted the object. Five scenarios were used in total; two for training, and three for data collection. Each training scenario ran for 10 minutes and each data collection scenario ran for 15 minutes. The first training scenario was intended to teach participants on the basics of maneuvering their units and understanding the interface. Only one fire was present in this scenario so participants could train in fighting it.

The second training scenario was noticeably more difficult than the first. Three fires started simultaneously, making this training scenario a “baptism by fire”, if you will. This challenge further highlighted the concept and importance of teamwork. The three data scenarios shared the same map but were rotated 90º in different directions to give the illusion of a new setting. The only things that differed between them were the locations of where fires would start and, more importantly, the ignite time configuration. There were three fires in each scenario, one of which always began immediately at the start of each scenario. Participants received an automated email message from the system telling them the location of this initial fire. Fires two and three, however, were not advertised, leaving teams with the responsibility of finding them. Fire number two began four minutes into each scenario, and the third and final fire began after 10 minutes had passed in total and only five minutes remained. This left teams with the prospect of possibly fighting one fire for four minutes, two fires for six minutes, and three fires for a maximum of five minutes.

To control for any learning effects, groups of teams encountered the three scenarios in different order. This order was in a sense semi-determined – it was decided beforehand that the twelve teams were to be divided into three groups of teams where each group encountered a different scenario order. The idea being that no group of four teams were to play the same scenario in any given order. It was decided upon the arrival of the first team in each block which order should be implemented to make this work. The same scenario order was then used for the three subsequent teams in that block. The first block of four teams began by playing the medium scenario (D1-80), followed by the difficult scenario (D2-60), and lastly the easy scenario (D3- 100). The second block of four teams played the difficult scenario first, then the easy scenario, and finished by playing the medium scenario. The third and final block of teams first played the easy scenario, then the medium scenario, and finally the difficult scenario.


Map

IMap

Objects

The scenario contain the following map objects.

Objects on map
Fire
Spread
Delay
Normal 1 Normal
Birch Birch 2 Slow
Pine Pine 0.5 Fast

Fuel

Fuel

Water

Water
House House
Tent Tent
People People
Medical Transit Point Medical Transit Point
Big landing area Big landing area


Maps

The experiment did use four maps.

IMap 1
        
Map 2
        
Map 3
        
Map 4

Map 1
Orginal
CanSwe1-C1-F80.con

Map 2
Rotate Left
CanSwe1-C2-F60.con

Map 3
Flip Vertical
Rotate Right
CanSwe1-C3-F100.con

Map 4
Rotate Right
Not Used


People

The task for the search and rescue chef is to evacuate people if needed.
The area contain the following people that may need to evacuate.

IMap 1
        
Map 2
        
Map 3
        
Map 4

Map 1

Map 2

Map 3

Map 4


Organisation

Organisation

Units

Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Fire Fighting Units
Logistic Logistic Logistic Logistic Units
Search and Rescue Search and Rescue Search and Rescue Units
Drone Drone / UAV

Roles

Information Chief

This role’s main objective is to provide the other roles with extended information about the state of the environment.

The Information Chief had access to a Drone / UAV (Unmanned Aerial Vehicle) unit that could scout the map to look for fires, houses, or civilians. The UAV is faster compared to its ground unit counterparts and can therefore cover the area faster. The UAV can also see a larger view, 5x5 squares, as opposed to the 3x3 square for all other units in the system. The UAV has several options for patrolling and can engage in different patrol patterns, such as circling a certain location and moving between different points. In this way, the Information Chief had the option of instructing the UAV to patrol certain areas autonomously and instead focus his or her efforts on instructing the other team members through the mail system.

For the Information Chief there is a choice between providing support to current events or scouting for new events. The Information Chief is not dependent on any resource and therefore isn’t as dependent on the Logistics Chief as the other roles.

The Information Chief could also tag individual squares on the map with icons for fire, houses, civilians, etc., to alert the other team members of events outside their own line of sight.


Fire Chief

The objective for the Fire Chief is to putting out the forest fire.

The Fire Chief commands five fire fighting units and had the main responsibility of putt out fires. The Fire Chief can also command Logistics Chief and the Search and Rescue Chief to use the extra four fire fighting units.

The fire fighting units needed to be provided with water to function efficiently but had an unlimited amount of fuel. Therefore the Fire Chief needs to communicate with the Logistics Chief to ensure that there is a supply of water ready. The fire fighting units are highly dependent on the efforts of the logistics chief to get water. However, the Fire Chief could choose to refill the fire fighting units with water at certain water pumps scattered across the map.

When a fire is located the Fire Chief must relocate an appropriate amount of firefighter units to the fire. The Fire Chief must also keep in mind that fires can spread and start in several locations at once, so the Fire Chief must be strategic with the use of the available firefighter units.


Logistics Chief

The main objective for the Logistics Chief is to distribute water to the fire fighting units and fuel to the Search and rescue units. The Logistics Chief also have two support fire fighting units that can be used under command from the Fire Chief.

The logistics chief have three water and fuel trucks, two of which carried only water, the third one transported both water and fuel. A logistics unit can only hold a limited amount of water, so as the logistic trucks support the other units the Logistics Chief must keep track of the amount of water available in each truck. Therefore, the Logistics Chief must plan and strategize the use of logistic units as to ensure no fire truck depletes its water supply. If a logistics unit completely runs out of water the unit must move to a water station to resupply. The logistics unit that can supply fuel have an unlimited fuel tank that does not require refilling. The Logistics Chief can see the position of the water and fuel pumps on the map.


Search and Rescue Chief

The main objective of this role is to find and rescue civilians that are spread out around the map. The Search and Rescue Chief also have two support fire fighting units that can be used under command from the Fire Chief.

These individuals that may need to be rescued can be positioned in the woods, in houses or at camp-sites. The Search and Rescue Chief have two rescue units that could carry four civilians at a time. The rescued individuals needs to be transported to a hospital before the Search and Rescue Chief can attempting to rescue more individuals.

The rescue vehicles needed fuel to move around, and could fill up with fuel at a fuel pump or by the logistic fuel unit commanded by the Logistic Chief. While the rescue unit could locate stranded civilians on their own, their short viewing distance meant that the Search and Rescue Chief benefited substantially from the efficient information flow provided by the Information Chief.





Screen Pictures

Manager

Manager

Chief

Manager

Uav

Fire Fighter

Manager

Logistics

Manager

Rescue

Manager

Rescue


Photos

Files

Experiment

Player Instructions
Configurations
Video Recordings
Logfiles

End State

End state in the last session for the groups.

Slow fire         
G01-S3-C2
        
Ignit time 2
        
Ignit time 3
        
Ignit time 3

Group 1

Group 2

Group 3

Group 4

Normal fire         
G01-S3-C2
        
Ignit time 2
        
Ignit time 3
        
Ignit time 3

Group 5

Group 6

Group 7

Group 8

Fast fire         
G01-S3-C2
        
Ignit time 2
        
Ignit time 3
        
Ignit time 3

Group 9

Group 10

Group 11

Group 12


All Sessions

Unit movement and fire development images and video all sessions in the experiment series.


Project - Group-01 - Group-02 - Group-03 - Group-04 - Group-05 - Group-06 - Group-07 - Group-08 - Group-09 - Group-10 - Group-11 - Group-12

Analysis

Publications

(Bjurling 2017) Most valuable player? - Assessing the impact of individual team role activity on team performance in a microworld environment

Artur : Oscar Bjurling
Type : Bachelor thesis, Linköping University, Sweden.
The full thesis can be downloaded at: http://liu.diva-portal.org/smash/get/diva2:1111835/FULLTEXT01.pdf

Abstract
Studying team performance dynamics in tasks and activities has proven difficult because of the dynamic and unpredictable nature of the real world. Microworld systems aim to address that issue by providing researchers with controllable simulated environments that captures the essence of their real-world counterpart activities. This study utilized one such microworld system, called C3Fire, to simulate a forest firefighting setting where 48 participants divided into 12 teams were tasked with cooperating in extinguishing the fires. Teams consisted of four roles – each with its different responsibilities and resources. The aim of this study was to determine whether any individual team role had a greater impact on team performance than the other roles. Each team encountered three distinct scenarios of varying difficulty. Command input action counts and self-assessed performance scores were collected for each participant. These measurements were tested for correlations with team scores. The logistics chief role, who was responsible for re-filling and re-fueling other units, stood out as being the only role whose command input count correlated with team score, and being one of only two roles for which command inputs and self-assessed performance scores were correlated, as well. Results of a multiple regression procedure also indicated that the command counts of the logistics chief was a significant predictor of team score.


(Weilandt 2017) Individual Workload’s Relation to Team Workload - An investigation

Artur : Jacob Weilandt
Type : Bachelor thesis, Linköping University, Sweden.
The full thesis can be downloaded at: http://liu.diva-portal.org/smash/get/diva2:1111849/FULLTEXT01.pdf

Abstract
There is an ongoing debate regarding the construct of team workload and a central point in that debate is team workload’s relation to individual workload. This study set out to investigate this relationship. To assess the participants’ workload a microworld called C3Fire was used to simulate a complex control situation in which teams had to cooperate to complete the task of fighting a forest fire. Twelve teams that consisted of four members in each team were recruited. In the microworld each member of the team took on one out of four separate roles and completed three different scenarios with varying degree of difficulty in C3Fire. After each scenario, a number of questionnaires aimed at gauging different aspects of the teams’ experience in the microworld were administered. The questionnaire in focus of the current study was the DATMA questionnaire, which was used to measure individual workload and team workload. To assert the relationship between the two constructs a multiple linear regression was conducted. The results provided showed that individual workload could be used as a significant predictor for modeling team workload. The study therefore concludes that there is evidence for a relationship in which each team members individual workload could be the parts of the total sum of team workload