Navigation and screen hierarchy in SCADA systems - Step-by-Step Execution

Process Flow - Navigation and screen hierarchy

Start at Main Screen

↓

Select Navigation Option

↓

Load Target Screen

↓

Display Screen Content

↓

User Interacts or Navigates Back

↓

Navigate to Another Screen

↓

Return to Previous Screen

↓

End or Repeat

This flow shows how a user starts at the main screen, selects navigation options, moves through screens in a hierarchy, and can interact or go back.

Execution Sample

SCADA systems

MainScreen -> Select Menu -> Load Screen -> Display Content -> User Action

This sequence represents moving from the main screen through navigation to a target screen and interacting with it.

Process Table

Step	Current Screen	User Action	Next Screen	Screen Loaded	Notes
1	Main Screen	Select 'Settings'	Settings Screen	Yes	User chooses Settings from main menu
2	Settings Screen	Select 'Network'	Network Screen	Yes	User drills down to Network settings
3	Network Screen	Press Back	Settings Screen	Yes	User returns to Settings screen
4	Settings Screen	Press Back	Main Screen	Yes	User returns to Main screen
5	Main Screen	Select 'Status'	Status Screen	Yes	User navigates to Status screen
6	Status Screen	No action	Status Screen	Yes	User views status, no navigation
7	Status Screen	Exit Application	None	No	User closes the application

💡 User exits application at step 7, ending navigation.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	Final
Current Screen	Main Screen	Settings Screen	Network Screen	Settings Screen	Main Screen	Status Screen	Status Screen	None
Screen Loaded	Main Screen Loaded	Settings Screen Loaded	Network Screen Loaded	Settings Screen Loaded	Main Screen Loaded	Status Screen Loaded	Status Screen Loaded	None

Key Moments - 3 Insights

Why does the screen change back to 'Settings Screen' at step 3 instead of going directly to 'Main Screen'?

Because the user pressed Back from 'Network Screen', which returns to the immediate previous screen 'Settings Screen' as shown in execution_table row 3.

What happens if the user does not perform any action on the 'Status Screen'?

The screen remains on 'Status Screen' with no navigation change, as shown in execution_table row 6 where 'No action' keeps the screen loaded.

How does the system know when to stop navigation?

When the user exits the application, navigation ends, indicated in execution_table row 7 with 'Exit Application' and no next screen loaded.

Visual Quiz - 3 Questions

Look at the execution table, what is the current screen after step 2?

A Main Screen

B Settings Screen

C Network Screen

D Status Screen

💡 Hint

Check the 'Current Screen' column at step 2 in the execution_table.

At which step does the user return to the Main Screen after navigating away?

A Step 3

B Step 4

C Step 5

D Step 6

💡 Hint

Look for when 'Current Screen' changes back to 'Main Screen' in the execution_table.

If the user pressed Back at step 6 instead of no action, what would be the next screen?

A Main Screen

B Settings Screen

C Status Screen

D Network Screen

💡 Hint

Consider the navigation hierarchy and back action from 'Status Screen' in the variable_tracker.

Concept Snapshot

Navigation starts at a main screen.
User selects options to move through screens.
Each screen loads content based on selection.
Back action returns to previous screen.
Exit ends navigation.
Screens form a hierarchy for user flow.

Full Transcript

This visual execution traces navigation in a SCADA system screen hierarchy. The user begins at the Main Screen and selects options to move to other screens like Settings and Network. Each step shows the current screen, user action, and next screen loaded. Back actions return to the previous screen, maintaining a clear navigation path. When the user exits, navigation ends. Variables track the current screen and loaded screen at each step, helping understand screen transitions. Key moments clarify why screens change as they do and when navigation stops. Quizzes test understanding of screen states and navigation flow based on the execution table and variable tracker.

Practice

1. What is the main purpose of navigation and screen hierarchy in SCADA systems?

easy

A. To organize screens in a clear tree structure for easy access

B. To increase the number of screens in the system

C. To make screens load slower for security

D. To hide all screens from the user

Solution

1. Step 1: Understand navigation purpose

   Navigation helps users find screens quickly by organizing them logically.

2. Step 2: Understand screen hierarchy role

   Hierarchy arranges screens as parents and children, creating a clear structure.

3. Final Answer:

   To organize screens in a clear tree structure for easy access -> Option A

4. Quick Check:

   Navigation = Organize screens clearly [OK]

Hint: Think of folders organizing files for easy finding [OK]

Common Mistakes:

• Confusing more screens with better navigation
• Thinking navigation slows system
• Believing screens should be hidden

2. Which of the following is the correct way to define a parent-child relationship between screens in a SCADA configuration file?

easy

A. "ScreenA": { "children": ["ScreenB", "ScreenC"] }

B. "ScreenA": { "parent": ["ScreenB", "ScreenC"] }

C. "ScreenA": { "siblings": ["ScreenB", "ScreenC"] }

D. "ScreenA": { "children": "ScreenB", "ScreenC" }

Solution

1. Step 1: Identify correct syntax for children

   Children are listed as an array under the key "children" for a parent screen.

2. Step 2: Check options for correct JSON structure

   "ScreenA": { "children": ["ScreenB", "ScreenC"] } uses an array correctly; others misuse keys or syntax.

3. Final Answer:

   "ScreenA": { "children": ["ScreenB", "ScreenC"] } -> Option A

4. Quick Check:

   Children = array under "children" key [OK]

Hint: Children screens go inside a list under "children" [OK]

Common Mistakes:

• Using "parent" key to list children
• Listing children without brackets
• Using "siblings" key incorrectly

3. Given this screen hierarchy configuration snippet:

{
  "MainScreen": { "children": ["AlarmScreen"] },
  "AlarmScreen": { "children": ["DetailScreen"] },
  "DetailScreen": {}
}

What is the correct navigation path to reach DetailScreen starting from MainScreen?

medium

A. MainScreen > DetailScreen > AlarmScreen

B. DetailScreen > AlarmScreen > MainScreen

C. AlarmScreen > MainScreen > DetailScreen

D. MainScreen > AlarmScreen > DetailScreen

Solution

1. Step 1: Read the hierarchy from the configuration

   MainScreen has AlarmScreen as child; AlarmScreen has DetailScreen as child.

2. Step 2: Trace the path from MainScreen to DetailScreen

   Navigate MainScreen to AlarmScreen, then AlarmScreen to DetailScreen.

3. Final Answer:

   MainScreen > AlarmScreen > DetailScreen -> Option D

4. Quick Check:

   Parent to child order = MainScreen > AlarmScreen > DetailScreen [OK]

Hint: Follow children arrays step-by-step [OK]

Common Mistakes:

• Reading hierarchy backwards
• Skipping intermediate screens
• Mixing order of screens

4. You have this incorrect screen hierarchy configuration:

{
  "MainScreen": { "children": "AlarmScreen" },
  "AlarmScreen": { "children": ["DetailScreen"] }
}

What is the main error and how to fix it?

medium

A. DetailScreen should be a child of MainScreen directly

B. Children key should be "parent" instead

C. Children must be a list; change "children": "AlarmScreen" to "children": ["AlarmScreen"]

D. Remove the children key from AlarmScreen

Solution

1. Step 1: Identify data type error in children key

   Children must be a list (array), but "AlarmScreen" is a string here.

2. Step 2: Correct the children value to a list

   Wrap "AlarmScreen" in brackets to make it a list: ["AlarmScreen"].

3. Final Answer:

   Children must be a list; change "children": "AlarmScreen" to "children": ["AlarmScreen"] -> Option C

4. Quick Check:

   Children = list, not string [OK]

Hint: Children always use square brackets [] [OK]

Common Mistakes:

• Using string instead of list for children
• Confusing children with parent key
• Changing unrelated keys

5. You want to design a SCADA screen hierarchy where MainScreen has two children: AlarmScreen and StatusScreen. AlarmScreen further has a child DetailScreen. Which JSON configuration correctly represents this hierarchy?

hard

A. {
"MainScreen": { "children": ["DetailScreen"] },
"AlarmScreen": { "children": ["StatusScreen"] },
"StatusScreen": {},
"DetailScreen": {}
}

B. {
"MainScreen": { "children": ["AlarmScreen", "StatusScreen"] },
"AlarmScreen": { "children": ["DetailScreen"] },
"StatusScreen": {},
"DetailScreen": {}
}

C. {
"MainScreen": { "children": ["AlarmScreen"] },
"AlarmScreen": { "children": ["StatusScreen", "DetailScreen"] },
"StatusScreen": {}
}

D. {
"MainScreen": { "children": ["StatusScreen"] },
"AlarmScreen": { "children": ["DetailScreen"] },
"StatusScreen": {},
"DetailScreen": {}
}

Solution

1. Step 1: Check MainScreen children

   MainScreen must have AlarmScreen and StatusScreen as children; only { "MainScreen": { "children": ["AlarmScreen", "StatusScreen"] }, "AlarmScreen": { "children": ["DetailScreen"] }, "StatusScreen": {}, "DetailScreen": {} } matches this.

2. Step 2: Check AlarmScreen children

   AlarmScreen must have DetailScreen as child; { "MainScreen": { "children": ["AlarmScreen", "StatusScreen"] }, "AlarmScreen": { "children": ["DetailScreen"] }, "StatusScreen": {}, "DetailScreen": {} } correctly shows this.

3. Step 3: Verify other screens

   StatusScreen and DetailScreen have empty children, which is correct.

4. Final Answer:

   { "MainScreen": { "children": ["AlarmScreen", "StatusScreen"] }, "AlarmScreen": { "children": ["DetailScreen"] }, "StatusScreen": {}, "DetailScreen": {} } -> Option B

5. Quick Check:

   MainScreen children = AlarmScreen, StatusScreen; AlarmScreen child = DetailScreen [OK]

Hint: Match parent children exactly as arrays in JSON [OK]

Common Mistakes:

• Mixing children between screens
• Omitting children arrays
• Assigning wrong children to parents