124
Sensemaking in Safety Critical and Complex Situations
NoGo Areas and Alarm Execution
Part of an Electronic Navigational Chart ( ENC) was imported into a database in the
phone’s memory. From the ENC, only the polygons making up the area with a water
depth of less than 3 m at chart datum were kept. These polygons made up the “ NoGo
Area” that was used to alarm the navigator for grounding. Ideally, we would have
NoGo polygons for every decimetre, which would be turned on and off depending on
the set draught of the boat and the tidal situation. However, this would require large
memory storage or a constant online connection, so we decided to have just one NoGo
depth of 3 m for the test. The Norwegian Hydrographic Office delivered the necessary
depth contour with a h igh-resolution horizontal grid of 1 m. The internal map would
consist of polygons marking water depths between 3 m and 0 ( the beach line).
The timed alarm function was implemented using a vector extending from the
present position in the direction of the current course. The length of the vector was
dependent on the speed and the alarm time set. In the default setting, the alarm
was set to be triggered 30 seconds before the boat “ grounded” ( passed into the
3 m NoGo area polygon). At 10 knots, the length of the vector would be ( 10 knots *
(1,852 m/3,600 seconds) * 30 seconds) =154 m. The length and direction of the
course-speed vector was calculated from recent satellite positions. The precision was
dependent on the position rate the phone could muster, which in general was one
position per second ( 1 Hz). The alarm would be triggered when a c ourse-speed vector
intersected with a NoGo area polygon.
The air draught alarm was treated the same way using the same c ourse-speed vector intersecting a safety rectangle extending 15 m on both sides of bridges and power
lines. The set mast height would then be compared against the maximum air draught
allowed as stated as an attribute to the safety rectangle. In the test area, there was
only one power line and no bridges.
The Augmented Reality ( AR) Layer
The NoGo area polygon map was to be shown on top of camera image at the correct
position. The polygons should apparently be “ floating” on the surface of the water.
In order to do this, the map had to be georeferenced and projected using a virtual
camera positioned in virtual space as the real camera was in the real space. This
projection is a standard virtual reality ( VR) operation conducted in real time taking
the virtual camera’s height over the water ( preset to 2 m), direction ( from the phone’s
compass) and field of view ( preset to match the device’s camera) as in-parameters.
The course-speed vector was also made visible and projected into the camera
view: white when not in alarm mode but changing colour to red when an intersection
had taken place and the alarm was triggered. It was then red as long as it was intersecting with the NoGo polygons, thus visualising the alarm state, also when the aural
alarm was silenced. The initial intersection point was shown by an arrow.
The stability and precision of the satellite positions and the compass heading from
the internal phone sensors was an area of concern. The c ourse-speed vector triggering the alarm was created by extrapolating present course and speed into the future.
Low-pass filters were applied to these values to avoid large jumps due to unstable
satellite fixes. This was done to reduce the risk of false collision alarms. The point of
Sensemaking in Safety Critical and Complex Situations
NoGo Areas and Alarm Execution
Part of an Electronic Navigational Chart ( ENC) was imported into a database in the
phone’s memory. From the ENC, only the polygons making up the area with a water
depth of less than 3 m at chart datum were kept. These polygons made up the “ NoGo
Area” that was used to alarm the navigator for grounding. Ideally, we would have
NoGo polygons for every decimetre, which would be turned on and off depending on
the set draught of the boat and the tidal situation. However, this would require large
memory storage or a constant online connection, so we decided to have just one NoGo
depth of 3 m for the test. The Norwegian Hydrographic Office delivered the necessary
depth contour with a h igh-resolution horizontal grid of 1 m. The internal map would
consist of polygons marking water depths between 3 m and 0 ( the beach line).
The timed alarm function was implemented using a vector extending from the
present position in the direction of the current course. The length of the vector was
dependent on the speed and the alarm time set. In the default setting, the alarm
was set to be triggered 30 seconds before the boat “ grounded” ( passed into the
3 m NoGo area polygon). At 10 knots, the length of the vector would be ( 10 knots *
(1,852 m/3,600 seconds) * 30 seconds) =154 m. The length and direction of the
course-speed vector was calculated from recent satellite positions. The precision was
dependent on the position rate the phone could muster, which in general was one
position per second ( 1 Hz). The alarm would be triggered when a c ourse-speed vector
intersected with a NoGo area polygon.
The air draught alarm was treated the same way using the same c ourse-speed vector intersecting a safety rectangle extending 15 m on both sides of bridges and power
lines. The set mast height would then be compared against the maximum air draught
allowed as stated as an attribute to the safety rectangle. In the test area, there was
only one power line and no bridges.
The Augmented Reality ( AR) Layer
The NoGo area polygon map was to be shown on top of camera image at the correct
position. The polygons should apparently be “ floating” on the surface of the water.
In order to do this, the map had to be georeferenced and projected using a virtual
camera positioned in virtual space as the real camera was in the real space. This
projection is a standard virtual reality ( VR) operation conducted in real time taking
the virtual camera’s height over the water ( preset to 2 m), direction ( from the phone’s
compass) and field of view ( preset to match the device’s camera) as in-parameters.
The course-speed vector was also made visible and projected into the camera
view: white when not in alarm mode but changing colour to red when an intersection
had taken place and the alarm was triggered. It was then red as long as it was intersecting with the NoGo polygons, thus visualising the alarm state, also when the aural
alarm was silenced. The initial intersection point was shown by an arrow.
The stability and precision of the satellite positions and the compass heading from
the internal phone sensors was an area of concern. The c ourse-speed vector triggering the alarm was created by extrapolating present course and speed into the future.
Low-pass filters were applied to these values to avoid large jumps due to unstable
satellite fixes. This was done to reduce the risk of false collision alarms. The point of