Station Status Board – Task 4
The HashMap-based query system has been running smoothly for several weeks, and the crew has come to rely on it for quick subsystem checks. However, the station director has requested expanded reporting capabilities. She wants the status board to show not just current readings, but also the full operational context for each subsystem: the highest and lowest values recorded, how many measurements have been taken, when the data was last updated, and what threshold defines critical conditions.
The engineering team explains that this information has always been collected by the diagnostic system—it's in the status file alongside the current readings. Until now, your program has been ignoring these additional fields, reading only the subsystem name, current reading, and status. Now you need to parse and store all of the diagnostic data.
Looking at the status file, you can see the complete set of fields:
ReactorCooling 42% NORMAL 35% 58% 35% 127 14:23
PowerDistribution 119V NORMAL 115V 124V 117V 134 14:23
LifeSupport 198000ppm NORMAL 195000ppm 205000ppm 195000ppm 128 14:23
Navigation 0.02deg WARNING 0.00deg 0.08deg 0.05deg 131 14:23
ThermalRegulation 18C NORMAL 16C 22C 15C 129 14:23
WasteRecycling 87% NORMAL 82% 95% 80% 126 14:23
CommArray 94% NORMAL 89% 98% 85% 133 14:23
DockingClamps 3201kPa NORMAL 3150kPa 3280kPa 3100kPa 130 14:23
Each line contains: subsystem name, current reading, status, minimum value recorded, maximum value recorded, critical threshold, total measurement count, and last update time.
Your program needs to store all of this information so it can be queried. When a crew member asks about a specific subsystem, they should see the complete diagnostic picture. Following the HashMap approach from the previous task, you'll need to create separate HashMaps for each piece of information: one for current readings, one for statuses, one for minimum values, one for maximum values, one for thresholds, one for measurement counts, and one for update times.
When a user queries a subsystem, the program should display all available information:
Enter subsystem name (or 'quit' to exit): ReactorCooling
ReactorCooling: 42% [NORMAL]
Range: 35% to 58%
Critical threshold: 35%
Measurements recorded: 127
Last updated: 14:23
Enter subsystem name (or 'quit' to exit): Navigation
Navigation: 0.02deg [WARNING]
Range: 0.00deg to 0.08deg
Critical threshold: 0.05deg
Measurements recorded: 131
Last updated: 14:23
Enter subsystem name (or 'quit' to exit): quit
Session ended.
As you implement this, you'll notice that managing seven different HashMaps becomes cumbersome. Each time you read a line from the file, you need to add seven entries—one to each HashMap—all using the same subsystem name as the key. When you query a subsystem, you need to retrieve seven different values and make sure they all correspond to the same system. If you make a mistake and use the wrong key in one HashMap, or forget to update one of them, the data becomes inconsistent.
Looking ahead: The chief engineer reviews your code and acknowledges that this approach works, but points out that it feels unnatural. "All of this data describes a single subsystem," she says. "We're treating it like seven separate pieces of information that happen to share a name, but really it's one thing with multiple properties." She mentions that there's a way to represent this more directly in code, something you'll explore in the next task.